From abdussalambaryun@gmail.com Tue Jan 1 00:29:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB93121F8499 for ; Tue, 1 Jan 2013 00:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gmnrfSNU8v0 for ; Tue, 1 Jan 2013 00:29:49 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id EF85221F8475 for ; Tue, 1 Jan 2013 00:29:21 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so13331287vba.41 for ; Tue, 01 Jan 2013 00:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vENw97MJlzs2fiL52rC3bMcLTzQt14aLN6IVQOLlPP0=; b=w4l6yw2Fgtm+gMNhCOcn2LKl3EYud8q99UGQlHJsX9UiARSIC7QfvyAeZdSCQp43Po LeKCp3HnW1Pi9hRmf7WFblTzoXLUysto6OpTq9V02GkT+BKgsp36DLqJMmPtBM9XaYVG z4gADNclvNqAVHfhhpf0H5s1Gnf0BlpxW3elXcJLybV+kapNUw8NjN5xj+xfeqN2T+Gt OgpT3R9UigSlPuJBlvHuPEBummNJD3hL0X8iD/Yfvi+il1Eozlf6BQV255zfzXXVB5rt 1E5hJ+0kBSZWakWJTM1pI2PYB7dMaf20KWuslrDViNI16chcoJ5RTb/MQUn4WrVjWxag SukQ== MIME-Version: 1.0 Received: by 10.58.252.72 with SMTP id zq8mr69977556vec.20.1357028961347; Tue, 01 Jan 2013 00:29:21 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 1 Jan 2013 00:29:21 -0800 (PST) In-Reply-To: <50E0C2D5.6030404@computer.org> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> Date: Tue, 1 Jan 2013 09:29:21 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 08:29:49 -0000 Thanks for the update. Does the proposal also mean that AODVv2 will not need to use SMF for MANET multicast? AB On 12/30/12, Charles E. Perkins wrote: > Hello folks, > > As noted by Marius Portmann et al., there are some subtleties about > using sequence numbers to inhibit dissemination of possibly > outdated RREQ and RREP messages. After reconsidering this > matter for the last couple of weeks, I realized that the existing > specification does not properly handle suppression of duplicate > multicast messages. In order to accomplish that, while still > not suppressing earlier multicast messages that do need to be > transmitted, a list of previously retransmitted multicast AODVv2 > routing messages needs to be maintained, as suggested by Marius. > > Here is some proposed text for that purpose: > > Two incoming RREQ messages should be considered the "same" if > they have the same Sequence Number and were generated by the same > AODVv2 router. Using that notion of equivalence, when RREQ messages > are multicast in a MANET, a node may well receive the same RREQ from > more than one of its neighbors. Such duplicated RREQs SHOULD NOT > be retransmitted; otherwise, a great deal of unnecessary signaling > traffic is likely to be generated in the network as multicast RREQs > are retransmitted over and over again with practically no additional > benefit. > > To avoid unnecessary retransmission of duplicate RREQ messages, > while still enabling the proper handling of earlier RREQ messages > that may have somehow been delayed in the network, it is needed > for each AODVv2 router to keep a list of the RREQ messages which > it has recently retransmitted. > > The same duplicate suppression is needed for other AODVv2 messages. > For instance, when optional multicast RREP is used to enable selection > from among multiple possible return routes, similar measures need to > be taken. > > For this reason, the table is more generally called the AODVv2 > Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ > and RREP messages which have been recently multicast, using > the above notion of message equivalence. More formally, two > AODVv2 RREQ messages are equivalent if: > - they were generated by the same AODVv2 router (RREQ_gen) > - RREQ_Gen assigned the same Sequence Number to its > routing information in the RREQs > - the RREQs are for the same desired destination address > An analogous definition applies for a RREP message, in case that > the RREP message would be multicast. > > Protocol handling of RERR messages eliminates the need for > tracking RERR messages, since the rules for retransmitting RERR > multicast messages prevent the phenomenon of message duplication > (that can affect RREQ and RREP retransmission). > > As a historical note, AODV and early versions of DYMO contained > a similar broadcast suppression mechanism. Prior to initiating the > conversion to RFC 5444 compliance, Ian and I had thought that the > underlying multicast optimization would do a better > job of duplicate suppression, and in a manner already integrated > with the underlying forwarding mechanisms. Thanks, Marius et al. > for triggering a re-examination of this issue which has needed > attention since the RFC 5444 compliance changes. > > On 12/13/2012 6:09 PM, Marius Portmann wrote: >> >> Hi Charlie, >> >> .................... >> >> >> (2) Route Reply Loss >> >> >> -------------------- >> >> >> AODV can lose route replies >> (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). >> >> >> The reason is that route replies are only forwarded by an >> >> >> intermediate node when the node updates its routing table. >> >> ................ > >> > The relevant point is that an AODVv2 router retransmits the RREQ or >> >> > RREP regardless of whether the AODVv2 router used the incoming >> >> > routing information to update its route table. >> >> > >> >> > I thought there might be some wording to the contrary, but after >> >> > reading the relevant parts of the specification several times I >> >> > haven't found any such wording. Please let me know what I have missed. >> >> Our analysis was based on DYMO/AODVv2 version 23. It now appears that >> in version 24, the specification has changed such that it is similar >> to what we are proposing, i.e. to let the AODVv2 routers always >> forward the RREQ/RREP messages. >> >> All the best, >> >> Rob, Peter, Marius and Wee Lum >> >> > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Tue Jan 1 00:49:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F2621F855C for ; Tue, 1 Jan 2013 00:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p17lxZKclP9B for ; Tue, 1 Jan 2013 00:49:07 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD6221F854D for ; Tue, 1 Jan 2013 00:49:06 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so13415058vcb.17 for ; Tue, 01 Jan 2013 00:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZQ/wyV8ad7TvaggN02xJxEhXNEHlq1nj8R/L7hDk1VU=; b=aPjUFZfqo0PQVAn85Wg+zPc3NO/FBJ9zRfAohq3QdBVuMlEjNjfWDpu7goMDQ1Ozz3 BujklAy8qRNgrlcloLrXc4WJVWgrsDjeKUfuaqjx/1n9AHNqQkJzRDVgWxXYflDtiwRm bClR9sFbmhIE1r0gFLB3qqv6HvOawAQIz7CpSvrR5zkaetOLcTBxxI64oQ72Kwx5F2Pl rGgT6kI4wC8efR9EYBEb3LdqhVfIcGp+f7Is9pHAdHgjYOCP+lUzJ29mHRDH9g+ZwJSi XNW3no5fQyHwdXndZ7iTKnCcllOSlmFD1JQ72vguVttjB3aIZgQIZlZCy2mACvUNvPhI ZVmQ== MIME-Version: 1.0 Received: by 10.58.243.166 with SMTP id wz6mr69632281vec.28.1357030146487; Tue, 01 Jan 2013 00:49:06 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 1 Jan 2013 00:49:06 -0800 (PST) In-Reply-To: <50E0C423.7020009@computer.org> References: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> <50BCA857.8070400@fkie.fraunhofer.de> <50BFC05E.4030006@computer.org> <50C05967.405@fkie.fraunhofer.de> <50E0C423.7020009@computer.org> Date: Tue, 1 Jan 2013 09:49:06 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 08:49:08 -0000 Thanks. Regarding message-names, I was not happy with the names OrigRtr, and RteMsg, because still remember the msg-names of RFC3561, but never objected because not necessary, however, I agree/like the amendment :) AB On 12/30/12, Charles E. Perkins wrote: > Hello Henning, > > I have been thinking a lot about the readability issues. > > Here are notational devices used in the current specification: > > | Route[DestAddr] | A route table entry towards DestAddr | > | Route[Addr].{field} | A field in a route table entry | > > I am assuming these are O.K. > > | -- | -- | > | | RFC 5444 Message Header | > | | RFC 5444 Message Header | > | AddrBlk | an RFC 5444 Address TLV Block | > | AddrBlk[1] | The first address slot in AddrBlk | > | AddrBlk[N] | The Nth address slot in AddrBlk | > | AddrBlk[OrigNode] | AddrBlk[1] | > | AddrBlk[TargNode] | AddrBlk[2] | > | AddrTLV | an RFC 5444 Address Block TLV | > | AddrTLV[1] | the first item in AddrTLV | > | AddrTLV[N] | the Nth item in AddrTLV | > | AddrTLV[OrigNode] | AddrTLV[1] | > | AddrTLV[TargNode] | AddrTLV[2] | > > These are pretty intuitive, given the notation already in RFC 5444. > > | SeqNumTLV | Sequence Number AddrTLV for AddrBlk | > > Looks O.K. to me...? > > | OrigNode | Originating Node | > | RREQ_Gen | AODVv2 router originating an RREQ | > | RREP_Gen | AODVv2 router responding to an RREQ | > | RteMsg | Either RREQ or RREP | > | RteMsg.{field} | Field in RREQ or RREP | > | RteMsg_Gen | Router generating a RteMsg | > | HandlingRtr | Handling Router | > | TargNode | Target Node | > | UnreachableNode | Unreachable Node | > > I am guessing that, if you find any of the notation difficult to read, > it would be one of these. I have been steadily reducing the number of > different such notations over time, but the above seem to be very useful > and seem pretty transparent to me. > > I have replaced "OrigRtr" by "RREQ_Gen" and "TargRtr" by "RREP_Gen" in > the version I am editing now. This has the advantage of reducing the > number > of notational devices, but did require some rewording of certain sentences > that seemed to make better sense with the earlier notation. > > The case for using "RteMsg" to stand for either RREQ or RREP is pretty > strong, for anyone who believes in eliminating redundancy in specification. > There are quite many protocol actions that are the same for RREQ as they > are for RREP. To write the relevant sections twice seems wrong to me. > However, I am quite open to using any other terminology if there are > suggestions for improvement. For instance, one could replace all > instances of "RteMsg" by "RREQ_or_RREP", but (it seems to me) that > would typically *reduce* readability instead of enhancing it. > > If the claim is that *any* such abbreviations should be replaced with > fully spelled out words, then we should have a discussion. For instance, > "UnreachableNode" is equally readable as "Unreachable Node", but the former > has the advantage of immediately connoting a distinguished term in the > document. I tried to have a discussion about this before, using > "F = ma" as an example (no one complained about the mistake in the > previous example, surprisingly to me). As I said before, to someone > who knows what 'F', 'm', and 'a' mean, "F = ma" is a lot more readable > than "Force is the same as the product of mass and acceleration". > Even more to the point, "F = ma" is pretty easy to remember. > But to someone who has never before encountered the abbreviations for > those fundamental quantities, "F = ma" is impenetrable. > > To reiterate after having said all that, I always remain quite open > to suggestions for ways to improve the notation. > > If there are other concerns about readability, please do not hesitate > to point them out. I have made major improvements in document > organization and editorial style during the last two months, and > so I hope that you can take a fresh look. > > On 12/6/2012 12:37 AM, Henning Rogge wrote: >> On 12/05/2012 10:45 PM, Charles E. Perkins wrote: >>> >>> Hello Henning, >>> >>> Here is some more follow-up on your observations and suggestions. >>> >>> On 12/3/2012 5:25 AM, Henning Rogge wrote: >>>> >>>> > Handling Router (HandlingRtr) >>>> > HandlingRtr denotes the AODVv2 router handling an AODVv2 message. >>>> >>>> Do you really need the "HandlingRtr" abbreviation? It complicates the >>>> text and does not shorten it that much. >>> >>> Would you like to see this terminology changed to instead be "Handler"? >>> I guess there's no need to constantly remind the reader that the node >>> doing the AODVv2 processing is a "router"... >> >> I think we should have a discussion on the list if that many >> abbreviations are really useful/necessary for a draft/rfc. In my >> opinion they have no advantage (beyond saving a few characters) and >> make the draft harder to read. >> > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From levente.meszaros@gmail.com Wed Jan 2 07:47:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6275921F85D9 for ; Wed, 2 Jan 2013 07:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fenkAkJXKnII for ; Wed, 2 Jan 2013 07:47:44 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B221F85CE for ; Wed, 2 Jan 2013 07:47:43 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so12955855obb.12 for ; Wed, 02 Jan 2013 07:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Ecsm/kv4MzwkW0/1GabfiCO3sPa3cAGyjPmEdEBkyXY=; b=MB+9juGvYIPRUTpyh9mM5Juw678ptIDSokomw4XkS7PPQL9/bSHFF1Abz8sOmL1BIs lx6xzpCRAnNx5oGURwzt376KKIqv2Lub1qid5ix0+MCQRHQJA+nbklkU784yQCpNXJuh WGM6p3uIdNEf/YEbCdDO9tnIp6j8pmUBiQh4l0s/7IaQOCJUlPch9rMfxISVM4qms92m yndqydrguGHjNOGrVNgL7C+KhHbfxnzX1JdEXp90O5Z8CM2ZbC3JdC61P0QxjvRKCbjs DzUTSljJTufk7SXRlUa6bLFtbWJUfjf2p27qvliwgrCnFWyvJhgn6x0aWuAVe8TNrTo1 lKZQ== MIME-Version: 1.0 Received: by 10.182.78.228 with SMTP id e4mr37822092obx.77.1357141663362; Wed, 02 Jan 2013 07:47:43 -0800 (PST) Received: by 10.60.124.169 with HTTP; Wed, 2 Jan 2013 07:47:43 -0800 (PST) Date: Wed, 2 Jan 2013 16:47:43 +0100 Message-ID: From: =?ISO-8859-1?Q?Levente_M=E9sz=E1ros?= To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [manet] draft-ietf-manet-dymo-24.txt: handling route timeouts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 15:50:48 -0000 Hi, I'm writing a simulation model for DYMO using OMNeT++ and I'd like to ask for your help in interpreting some details of the draft. Chapter "6.3. Route Table Entry Timeouts" says: "During normal operation, AODVv2 does not require any explicit timeouts to manage the lifetime of a route. However, the route table entry MUST be examined be before using it to forward a packet, as discussed in Section 8.1. Any required expiry or deletion can occur at that time. Nevertheless, it is permissible to implement timers and timeouts to achieve the same effect. ... A route MUST be expunged if Current_Time >=3D Route.ExpirationTime." Chapter "8.1. Handling Route Lifetimes During Packet Forwarding" says: "If Current_Time > Route.ExpirationTime, the route table entry has expired, and a RERR SHOULD be generated." If I expunge expired routes using timers, when should I generate RERR messages? With this approach there are no expired routes when packets are forwarded. Also, when the route timer expires and the route is removed, there is no associated data packet to be forwarded, and there may have not been any at all. Thank you for your help. Best regards, Levente M=E9sz=E1ros From charliep@computer.org Wed Jan 2 09:58:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BEE21F871D for ; Wed, 2 Jan 2013 09:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M6EX3ay-uRq for ; Wed, 2 Jan 2013 09:58:19 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 18F6C21F8715 for ; Wed, 2 Jan 2013 09:58:19 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TqSa2-0008Aj-9r; Wed, 02 Jan 2013 12:58:18 -0500 Message-ID: <50E47537.6000906@computer.org> Date: Wed, 02 Jan 2013 09:58:15 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Levente_M=E9sz=E1ros?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866465fa18158483639045ade1e68efa16350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: Re: [manet] draft-ietf-manet-dymo-24.txt: handling route timeouts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 17:58:20 -0000 Hello Levente, As you point out, if the route is expunged when a timer alarm occurs, it is unlikely there will be a data packet affected, so no RERR is transmitted. In fact, any other router that has the same route is likely to have it marked as expiring at the same time, so the RERR would not offer any benefit. RERRs are intended to avoid transmission of unrouteable packets. Expunging routes which have expired would typically not affect the routability of any packets. If you can suggest inclusion of text to make this more clear, that would be appreciated! Regards, Charlie P. On 1/2/2013 7:47 AM, Levente Mészáros wrote: > Hi, > > I'm writing a simulation model for DYMO using OMNeT++ and I'd like > to ask for your help in interpreting some details of the draft. > > Chapter "6.3. Route Table Entry Timeouts" says: > > "During normal operation, AODVv2 does not require any explicit > timeouts to manage the lifetime of a route. However, the route table > entry MUST be examined be before using it to forward a packet, as > discussed in Section 8.1. Any required expiry or deletion can occur > at that time. Nevertheless, it is permissible to implement timers > and timeouts to achieve the same effect. > ... > A route MUST be expunged if Current_Time >= Route.ExpirationTime." > > Chapter "8.1. Handling Route Lifetimes During Packet Forwarding" says: > > "If Current_Time > Route.ExpirationTime, the route table entry has > expired, and a RERR SHOULD be generated." > > If I expunge expired routes using timers, when should I generate RERR > messages? With this approach there are no expired routes when packets > are forwarded. Also, when the route timer expires and the route is removed, > there is no associated data packet to be forwarded, and there may have > not been any at all. > > Thank you for your help. > Best regards, > Levente Mészáros > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From internet-drafts@ietf.org Thu Jan 3 16:42:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E33C21F85B4; Thu, 3 Jan 2013 16:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62-NOHUciYED; Thu, 3 Jan 2013 16:42:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38121F85ED; Thu, 3 Jan 2013 16:42:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130104004211.16087.20886.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 16:42:11 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dymo-25.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 00:42:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Ian D Chakeres Filename : draft-ietf-manet-dymo-25.txt Pages : 58 Date : 2013-01-03 Abstract: The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dymo There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dymo-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-25 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From charliep@computer.org Thu Jan 3 16:44:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A415121F8E0F for ; Thu, 3 Jan 2013 16:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzwm5-WrhuGZ for ; Thu, 3 Jan 2013 16:44:20 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6E21F8E0D for ; Thu, 3 Jan 2013 16:44:20 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TqvOV-0000pC-TL; Thu, 03 Jan 2013 19:44:20 -0500 Message-ID: <50E625E0.702@computer.org> Date: Thu, 03 Jan 2013 16:44:16 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ec4ad4ec8d1a3c12d435159c7d8053a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 00:44:21 -0000 Hello Abdussalam, AODVv2 should still use SMF techniques to build a reduced forwarding tree for the multicast messages. But it will work just fine with brute force forwarding. Regards, Charlie P. On 1/1/2013 12:29 AM, Abdussalam Baryun wrote: > Thanks for the update. Does the proposal also mean that AODVv2 will > not need to use SMF for MANET multicast? > > AB > > On 12/30/12, Charles E. Perkins wrote: >> Hello folks, >> >> As noted by Marius Portmann et al., there are some subtleties about >> using sequence numbers to inhibit dissemination of possibly >> outdated RREQ and RREP messages. After reconsidering this >> matter for the last couple of weeks, I realized that the existing >> specification does not properly handle suppression of duplicate >> multicast messages. In order to accomplish that, while still >> not suppressing earlier multicast messages that do need to be >> transmitted, a list of previously retransmitted multicast AODVv2 >> routing messages needs to be maintained, as suggested by Marius. >> >> Here is some proposed text for that purpose: >> >> Two incoming RREQ messages should be considered the "same" if >> they have the same Sequence Number and were generated by the same >> AODVv2 router. Using that notion of equivalence, when RREQ messages >> are multicast in a MANET, a node may well receive the same RREQ from >> more than one of its neighbors. Such duplicated RREQs SHOULD NOT >> be retransmitted; otherwise, a great deal of unnecessary signaling >> traffic is likely to be generated in the network as multicast RREQs >> are retransmitted over and over again with practically no additional >> benefit. >> >> To avoid unnecessary retransmission of duplicate RREQ messages, >> while still enabling the proper handling of earlier RREQ messages >> that may have somehow been delayed in the network, it is needed >> for each AODVv2 router to keep a list of the RREQ messages which >> it has recently retransmitted. >> >> The same duplicate suppression is needed for other AODVv2 messages. >> For instance, when optional multicast RREP is used to enable selection >> from among multiple possible return routes, similar measures need to >> be taken. >> >> For this reason, the table is more generally called the AODVv2 >> Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ >> and RREP messages which have been recently multicast, using >> the above notion of message equivalence. More formally, two >> AODVv2 RREQ messages are equivalent if: >> - they were generated by the same AODVv2 router (RREQ_gen) >> - RREQ_Gen assigned the same Sequence Number to its >> routing information in the RREQs >> - the RREQs are for the same desired destination address >> An analogous definition applies for a RREP message, in case that >> the RREP message would be multicast. >> >> Protocol handling of RERR messages eliminates the need for >> tracking RERR messages, since the rules for retransmitting RERR >> multicast messages prevent the phenomenon of message duplication >> (that can affect RREQ and RREP retransmission). >> >> As a historical note, AODV and early versions of DYMO contained >> a similar broadcast suppression mechanism. Prior to initiating the >> conversion to RFC 5444 compliance, Ian and I had thought that the >> underlying multicast optimization would do a better >> job of duplicate suppression, and in a manner already integrated >> with the underlying forwarding mechanisms. Thanks, Marius et al. >> for triggering a re-examination of this issue which has needed >> attention since the RFC 5444 compliance changes. >> >> On 12/13/2012 6:09 PM, Marius Portmann wrote: >>> Hi Charlie, >>> >>> .................... >>> >>>>> (2) Route Reply Loss >>>>> -------------------- >>>>> AODV can lose route replies >>> (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). >>> >>>>> The reason is that route replies are only forwarded by an >>>>> intermediate node when the node updates its routing table. >>> ................ >>>> The relevant point is that an AODVv2 router retransmits the RREQ or >>>> RREP regardless of whether the AODVv2 router used the incoming >>>> routing information to update its route table. >>>> I thought there might be some wording to the contrary, but after >>>> reading the relevant parts of the specification several times I >>>> haven't found any such wording. Please let me know what I have missed. >>> Our analysis was based on DYMO/AODVv2 version 23. It now appears that >>> in version 24, the specification has changed such that it is similar >>> to what we are proposing, i.e. to let the AODVv2 routers always >>> forward the RREQ/RREP messages. >>> >>> All the best, >>> >>> Rob, Peter, Marius and Wee Lum >>> >>> >> -- >> Regards, >> Charlie P. >> >> -- Regards, Charlie P. From charliep@computer.org Thu Jan 3 16:56:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7021F8877 for ; Thu, 3 Jan 2013 16:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gERCZLKm8Dty for ; Thu, 3 Jan 2013 16:56:39 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5799821F8609 for ; Thu, 3 Jan 2013 16:56:39 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TqvaQ-0004h1-Jd for manet@ietf.org; Thu, 03 Jan 2013 19:56:38 -0500 Message-ID: <50E628C3.6000604@computer.org> Date: Thu, 03 Jan 2013 16:56:35 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: manet@ietf.org References: <20130104004211.16087.20886.idtracker@ietfa.amsl.com> In-Reply-To: <20130104004211.16087.20886.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad862723faa24442174ae4f91fbeee59d978350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-25.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 00:56:40 -0000 Hello folks, The new revision reflects the comments and changes from messages on the list since the last IETF meeting. I did rework the approach to suppression of useless RREQ multicast messages, because it turns out to be a lot easier to describe the operation in terms of incoming multicast messages instead of in terms of the outgoing messages that are triggered by the incoming multicast. Moreover, I restricted the description to only deal with RREQ multicast messages. The same thing works for other flooded messages, but I don't think that's needed in the base part of the specification. I have been taking as many measures as I can find to improve readability. I also clarified various mandates, and there were some protocol actions that were specified as both SHOULD and MUST, for instance. I think I have fixed most of those. Other than that, there were some residual effects of having alternate metrics which needed attention, and various small corrections and clarifications. During proofreading, I identified some minor issues which I will put into the issue tracker tomorrow. Regards, Charlie P. On 1/3/2013 4:42 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Ian D Chakeres > Filename : draft-ietf-manet-dymo-25.txt > Pages : 58 > Date : 2013-01-03 > > Abstract: > The Dynamic MANET On-demand (AODVv2) routing protocol is intended for > use by mobile routers in wireless, multihop networks. AODVv2 > determines unicast routes among AODVv2 routers within the network in > an on-demand fashion, offering on-demand convergence in dynamic > topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dymo > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dymo-25 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dymo-25 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From afarrel@juniper.net Fri Jan 4 11:18:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7431721F888E for ; Fri, 4 Jan 2013 11:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrAB7HHw1-xq for ; Fri, 4 Jan 2013 11:18:33 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 79BD621F8887 for ; Fri, 4 Jan 2013 11:18:33 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r04JIVbW017179; Fri, 4 Jan 2013 19:18:31 GMT Received: from 950129200 (089144192219.atnat0001.highway.a1.net [89.144.192.219]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r04JIUiw017152; Fri, 4 Jan 2013 19:18:30 GMT From: "Adrian Farrel" To: "'Susan Hares'" , References: <000901cde1ec$141d2c00$3c578400$@ndzh.com> In-Reply-To: <000901cde1ec$141d2c00$3c578400$@ndzh.com> Date: Fri, 4 Jan 2013 19:18:30 -0000 Message-ID: <06be01cdeab0$48ecbaf0$dac630d0$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWmqcIIkTjqkUSl8UcoHxbMN4TQZkoGTsg Content-Language: en-gb Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: afarrel@juniper.net List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 19:18:34 -0000 Thanks Sue and Happy New Year, [snip] > Additional questions:=20 > 1) Will you suggest a style guide as well as a solution?=A0 In order = to > vote, I reviewed 2 months of email list discussion, and=20 > much of it had to do with document style issues.=20 You didn't vote, but I know what you mean :-) If "the AD chooses" is the way we go, then I expect the chairs will have = a long discussion with the editors of the document that the WG is working on, = and IO also expect that the WG will express a view about the way they want = their document presented. I will be happy to help in these discussions. > 2) In parallel with your query, can I still ask technical questions = regarding > people=92s comparison answer?=20 I don't see why not. The intention (if we don't strike the item from the charter) will be to produce one or two WG documents. Discussion seems = like a good idea. > 3) May I in parallel provide reactive trade-off from 802.11 work in > mesh? This includes research and deployment experience with mesh > networks (2-15 nodes). I believe that we can learn from the use of reactive protocols in 802.11 = (but see the answer to Q4).=20 > 4) Is this IP only or are we considering Reactive protocols directly > over layer 2?=20 You catch me in a cleft stick! I have an old-fashioned view of the IETF: = I believe it works on IP-related protocols. Thus, if we were proposing to = develop a reactive protocol for L2 use I would say it was out of scope. On the = other hand, if we have already developed a protocol for routing IP traffic and = there is a proposal to apply this protocol in L2 then I would think the IETF = could work on it. Perhaps the lever here is that in the IETF we optimize for IP. [Editor's note: MPLS is not IP :-) On the other hand, the MPLS control = protocols are carried by IP.] Maybe that helps? Adrian From jvasseur@cisco.com Sun Jan 6 02:31:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6821F8837 for ; Sun, 6 Jan 2013 02:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0mX1d+RVq1f for ; Sun, 6 Jan 2013 02:31:19 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0D521F881C for ; Sun, 6 Jan 2013 02:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2333; q=dns/txt; s=iport; t=1357468279; x=1358677879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UDXrcGVmS5BAo3GX9r571DDefKoslykJdApod5urgTw=; b=JqgwFB8FC4QJWIH4RYMoQhh/+YMJXNW+B6lDkiOYLWZHWuH0Og2m5AFg n2m6FN7Nn+fqsr36IYghQuW8/WvxzKieg+4XGZIHd/3yVSuraRvIk36ui 9Rvy4EoBwLO3f9DTuP+ugvFBsuF8VKIZx7fzkL7rEYhCLXAow6RwSFSAy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK9R6VCtJXHA/2dsb2JhbABFvVUWc4IeAQEBAwEBAQFkBwsFCwIBCCIkJwslAgQOBQgTh3YGDLUhBIxdg1dhA5JYk3yCdIFxNQ X-IronPort-AV: E=Sophos;i="4.84,419,1355097600"; d="scan'208";a="159308957" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 06 Jan 2013 10:31:19 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r06AVIRt030416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Jan 2013 10:31:18 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.144]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sun, 6 Jan 2013 04:31:18 -0600 From: "JP Vasseur (jvasseur)" To: "" Thread-Topic: [manet] Resolving the Reactive Protocol issue Thread-Index: AQHN6/j1N4wZFK6SI0W1WT0mR0nD0w== Date: Sun, 6 Jan 2013 10:31:17 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772319558C@xmb-rcd-x02.cisco.com> References: <000901cde1ec$141d2c00$3c578400$@ndzh.com> <06be01cdeab0$48ecbaf0$dac630d0$@juniper.net> In-Reply-To: <06be01cdeab0$48ecbaf0$dac630d0$@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.230] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 10:31:20 -0000 On Jan 4, 2013, at 8:18 PM, Adrian Farrel wrote: > Thanks Sue and Happy New Year, >=20 > [snip] >=20 >> Additional questions:=20 >> 1) Will you suggest a style guide as well as a solution? In order to >> vote, I reviewed 2 months of email list discussion, and=20 >> much of it had to do with document style issues.=20 >=20 > You didn't vote, but I know what you mean :-) >=20 > If "the AD chooses" is the way we go, then I expect the chairs will have = a long > discussion with the editors of the document that the WG is working on, an= d IO > also expect that the WG will express a view about the way they want their > document presented. I will be happy to help in these discussions. >=20 >> 2) In parallel with your query, can I still ask technical questions rega= rding >> people's comparison answer?=20 >=20 > I don't see why not. The intention (if we don't strike the item from the > charter) will be to produce one or two WG documents. Discussion seems lik= e a > good idea. >=20 >> 3) May I in parallel provide reactive trade-off from 802.11 work in >> mesh? This includes research and deployment experience with mesh >> networks (2-15 nodes). >=20 > I believe that we can learn from the use of reactive protocols in 802.11 = (but > see the answer to Q4).=20 >=20 >> 4) Is this IP only or are we considering Reactive protocols directly >> over layer 2?=20 >=20 > You catch me in a cleft stick! I have an old-fashioned view of the IETF: = I > believe it works on IP-related protocols. Thus, if we were proposing to d= evelop > a reactive protocol for L2 use I would say it was out of scope. On the ot= her > hand, if we have already developed a protocol for routing IP traffic and = there > is a proposal to apply this protocol in L2 then I would think the IETF co= uld > work on it. >=20 > Perhaps the lever here is that in the IETF we optimize for IP. JP> Glad to hear that =85 L2 control planes are different from IP, to say t= he least =85 IETF =3D=3D IP. >=20 > [Editor's note: MPLS is not IP :-) On the other hand, the MPLS control pr= otocols > are carried by IP.] >=20 > Maybe that helps? > Adrian >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sun Jan 6 19:09:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB05521F850C for ; Sun, 6 Jan 2013 19:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzNJGvgQcWW3 for ; Sun, 6 Jan 2013 19:09:42 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1752621F86C2 for ; Sun, 6 Jan 2013 19:09:42 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so18557745vbb.16 for ; Sun, 06 Jan 2013 19:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jDQTQ0ELG6zstu1Jhq00BEG8JJWUNKDfDF0K0iN7ZY4=; b=GYPyOgvxbs/KzmLWVP1DUw+dmMEgx54+XSdb9iLsi0SzJ4byMM3zkrBqLkCeq7yPKO ugRCAQrE/utxacKopzpccz2muY4QsyJ/0uP+YvQF/k036ffaxy4+ycYr2wWaU/FSrlKj Qf+7uh4IbNFLyhvRRXAm287lU4wAUpagyoamlw2ef4dEQlzmUnBv8a6DAKsr/O4wuxIc RD6EUQXYtTuzqbyUfqBVolvPZRoNbO1pQvuj5c07lFFHR2FGVwAmV1ZIlh3+41uTTIiE 4xnDDQrZ5EoY8DU7z4AQ3qI1TjTcILMMkcYa0EL+R4UMbkxcBCJS9Oh/wElIQyhTEl5i ib4g== MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr84339739veb.43.1357528181474; Sun, 06 Jan 2013 19:09:41 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sun, 6 Jan 2013 19:09:41 -0800 (PST) In-Reply-To: <50E628C3.6000604@computer.org> References: <20130104004211.16087.20886.idtracker@ietfa.amsl.com> <50E628C3.6000604@computer.org> Date: Mon, 7 Jan 2013 04:09:41 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-25.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 03:09:43 -0000 Thanks. Reviewed the ID and I think it is excellent, 14.3> delete repeated word *options*. 15.4> amend word *draft* to document. Regards AB On 1/4/13, Charles E. Perkins wrote: > > Hello folks, > > The new revision reflects the comments and changes from messages on the > list since the last IETF meeting. I did rework the approach to > suppression of > useless RREQ multicast messages, because it turns out to be a lot easier to > describe the operation in terms of incoming multicast messages instead of > in terms of the outgoing messages that are triggered by the incoming > multicast. Moreover, I restricted the description to only deal with RREQ > multicast messages. The same thing works for other flooded messages, > but I don't think that's needed in the base part of the specification. > > I have been taking as many measures as I can find to improve readability. > I also clarified various mandates, and there were some protocol actions > that > were specified as both SHOULD and MUST, for instance. I think I have fixed > most of those. > > Other than that, there were some residual effects of having alternate > metrics > which needed attention, and various small corrections and clarifications. > > During proofreading, I identified some minor issues which I will put > into the > issue tracker tomorrow. > > Regards, > Charlie P. > > > > On 1/3/2013 4:42 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of >> the IETF. >> >> Title : Dynamic MANET On-demand (AODVv2) Routing >> Author(s) : Charles E. Perkins >> Ian D Chakeres >> Filename : draft-ietf-manet-dymo-25.txt >> Pages : 58 >> Date : 2013-01-03 >> >> Abstract: >> The Dynamic MANET On-demand (AODVv2) routing protocol is intended for >> use by mobile routers in wireless, multihop networks. AODVv2 >> determines unicast routes among AODVv2 routers within the network in >> an on-demand fashion, offering on-demand convergence in dynamic >> topologies. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-dymo-25 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dymo-25 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From jvasseur@cisco.com Sun Jan 6 21:54:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E657321F8473 for ; Sun, 6 Jan 2013 21:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxePeA3m0zNX for ; Sun, 6 Jan 2013 21:54:40 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5853521F846E for ; Sun, 6 Jan 2013 21:54:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3110; q=dns/txt; s=iport; t=1357538080; x=1358747680; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5ATOY9m5ObWuSqS44W7TAhrn8O1rGSsEzZqeSP/7tsk=; b=OrVD8sqhkERYEn4u0yrMEocSMRtjYugryMeuMB9kLmBmkkKUy0ukrIMD jXFGY9iWK+Lp2vlkAtWXTy4aS2QvQ3g6j6iONlF1KvFzMzPXt4Kf3XFQY Fhpj+ngFQHBSyiKU/W7ZiOJsahhlwb0+NizUlkg9MbC/keRSuFRQPz9a9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAM5i6lCtJXG+/2dsb2JhbABFg2y5axZzgh4BAQEDAQEBATc0CxACAQgYChQQJwslAgQOBQgBiAgGBwW2GZA0YQOXJ48tgnSCJg X-IronPort-AV: E=Sophos;i="4.84,421,1355097600"; d="scan'208";a="159528689" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jan 2013 05:54:25 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r075sPNa011099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 05:54:25 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.144]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sun, 6 Jan 2013 23:54:25 -0600 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-25.txt Thread-Index: AQHN7JtyPlpw2BfV1EmBoCen/TuEDA== Date: Mon, 7 Jan 2013 05:54:24 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772319ABE4@xmb-rcd-x02.cisco.com> References: <20130104004211.16087.20886.idtracker@ietfa.amsl.com> <50E628C3.6000604@computer.org> In-Reply-To: <50E628C3.6000604@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.230] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CA697004601D54092CCD377013EFFC9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-25.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 05:54:42 -0000 Thanks Charlie, just a quick messiah e(will send more comments) to acknowle= dge the great work, really much better shape. Thanks. JP. On Jan 4, 2013, at 1:56 AM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > The new revision reflects the comments and changes from messages on the > list since the last IETF meeting. I did rework the approach to suppressi= on of > useless RREQ multicast messages, because it turns out to be a lot easier = to > describe the operation in terms of incoming multicast messages instead of > in terms of the outgoing messages that are triggered by the incoming > multicast. Moreover, I restricted the description to only deal with RREQ > multicast messages. The same thing works for other flooded messages, > but I don't think that's needed in the base part of the specification. >=20 > I have been taking as many measures as I can find to improve readability. > I also clarified various mandates, and there were some protocol actions t= hat > were specified as both SHOULD and MUST, for instance. I think I have fix= ed > most of those. >=20 > Other than that, there were some residual effects of having alternate met= rics > which needed attention, and various small corrections and clarifications. >=20 > During proofreading, I identified some minor issues which I will put into= the > issue tracker tomorrow. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > On 1/3/2013 4:42 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF. >>=20 >> Title : Dynamic MANET On-demand (AODVv2) Routing >> Author(s) : Charles E. Perkins >> Ian D Chakeres >> Filename : draft-ietf-manet-dymo-25.txt >> Pages : 58 >> Date : 2013-01-03 >>=20 >> Abstract: >> The Dynamic MANET On-demand (AODVv2) routing protocol is intended for >> use by mobile routers in wireless, multihop networks. AODVv2 >> determines unicast routes among AODVv2 routers within the network in >> an on-demand fashion, offering on-demand convergence in dynamic >> topologies. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-dymo-25 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-25 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Mon Jan 7 01:28:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8A921F8510 for ; Mon, 7 Jan 2013 01:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k+RzmIr+KUL for ; Mon, 7 Jan 2013 01:28:56 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD3921F84F6 for ; Mon, 7 Jan 2013 01:28:55 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ts90n-0001so-St for manet@ietf.org; Mon, 07 Jan 2013 10:28:53 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ts90n-0007Q0-QE for manet@ietf.org; Mon, 07 Jan 2013 10:28:53 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 7 Jan 2013 10:28:53 +0100 Message-ID: <50EA954E.802@fkie.fraunhofer.de> Date: Mon, 7 Jan 2013 10:28:46 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> In-Reply-To: <50E0C2D5.6030404@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020002090403050706040103" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16421/Mon Jan 7 09:40:11 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:28:57 -0000 --------------ms020002090403050706040103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Back from vacation... On 12/30/2012 11:40 PM, Charles E. Perkins wrote: > Hello folks, > > As noted by Marius Portmann et al., there are some subtleties about > using sequence numbers to inhibit dissemination of possibly > outdated RREQ and RREP messages. > ..... Its good that we are looking into this issue. > As a historical note, AODV and early versions of DYMO contained > a similar broadcast suppression mechanism. Prior to initiating the > conversion to RFC 5444 compliance, Ian and I had thought that the > underlying multicast optimization would do a better > job of duplicate suppression, and in a manner already integrated > with the underlying forwarding mechanisms. Thanks, Marius et al. > for triggering a re-examination of this issue which has needed > attention since the RFC 5444 compliance changes. Not sure SMF would apply to all of AODV anyways. SMF is for flooding a=20 message over the whole MANET, but some AODV messages are modified for=20 each hop. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020002090403050706040103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMDcwOTI4NTFaMCMGCSqGSIb3DQEJBDEWBBSZIzuix8nr//wK6hJr8/7DKjHuPzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAKK31Nws4diSK7l+bGnpghuSICm+6zzVkV9thzgTazdVi 8Nt29bXGy7sQ42uPicBPVo48gRDFUvCrQajO+P95/Kbh5h9IVc6my8Y7qhHZ5hElk07LKghR 0u+c1STGWs8Y7JciMvlO5TT9LsBklUpVVhUtQFh/+d6vZn0BqY4Y8w0vdJgGkTiLkD62mqsC 7n2VSRtuLHILlpqfLXBAeMAvEmIx7ZKGgztj6cADYpi8uUXi1UalqMIj7p6hnXMZ2ZFRfpW1 wTdbxt8B8kCGQyEdLx/oDBb6NJYbzSb5KapjJhf96IYR5Wsw7AVnJfkau8xMdIB6qAjG2BRW gDxUmhGyuAAAAAAAAA== --------------ms020002090403050706040103-- From henning.rogge@fkie.fraunhofer.de Mon Jan 7 01:32:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D01021F8556 for ; Mon, 7 Jan 2013 01:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVbF036dD2Z9 for ; Mon, 7 Jan 2013 01:32:49 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7617321F853A for ; Mon, 7 Jan 2013 01:32:49 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ts94a-0003b0-Qn for manet@ietf.org; Mon, 07 Jan 2013 10:32:48 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ts94a-0007ZT-OC for manet@ietf.org; Mon, 07 Jan 2013 10:32:48 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 7 Jan 2013 10:32:48 +0100 Message-ID: <50EA963F.50304@fkie.fraunhofer.de> Date: Mon, 7 Jan 2013 10:32:47 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <000901cde1ec$141d2c00$3c578400$@ndzh.com> <06be01cdeab0$48ecbaf0$dac630d0$@juniper.net> In-Reply-To: <06be01cdeab0$48ecbaf0$dac630d0$@juniper.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040904070602030200010607" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16421/Mon Jan 7 09:40:11 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Subject: Re: [manet] Resolving the Reactive Protocol issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:32:50 -0000 --------------ms040904070602030200010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/04/2013 08:18 PM, Adrian Farrel wrote: >> 4) Is this IP only or are we considering Reactive protocols directly >> over layer 2? > > You catch me in a cleft stick! I have an old-fashioned view of the IETF= : I > believe it works on IP-related protocols. Thus, if we were proposing to= develop > a reactive protocol for L2 use I would say it was out of scope. On the = other > hand, if we have already developed a protocol for routing IP traffic an= d there > is a proposal to apply this protocol in L2 then I would think the IETF = could > work on it. > > Perhaps the lever here is that in the IETF we optimize for IP. > > [Editor's note: MPLS is not IP :-) On the other hand, the MPLS control = protocols > are carried by IP.] I think MPLS can be a good solution to "solve" a routing problem on=20 layer 3 and then duplicate the results on layer 2 (or 2.5). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040904070602030200010607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMDcwOTMyNDdaMCMGCSqGSIb3DQEJBDEWBBQUSAY//z52t4EKS+ho/zzVG3DupzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAIqlcRATsaSns8HCCM07kU3kOVdF5tSHoY/2dsQTl9Pnp YrsgXaLBKgO3ci0Ik0TKSRc8ZePzaZVkWe8w0xvQHRG7XVzWcLftimiWtSrA4jK9z8sOl89d A8n7FYd4AXeu9grgArCMik7NVdkVBOUyxrLX8ZJL5s/kGLGSEXnbuzKcCLvtgZNjTWcFjKe3 pbhnyjoVjdXauXTmLr7LjCjzP+doWV/eogjGXwBdBmdHJfis7r65eRpm1OgYDMN+O90XCYmv NWUqFsoAKE/HUWDdakp3AP40BOdvmva13lUjH8JkYxNj5v3wwY8gf3FsPUqYe93P1DjjcpKm hIOmEGc3kgAAAAAAAA== --------------ms040904070602030200010607-- From charliep@computer.org Mon Jan 7 09:10:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9A821F8929 for ; Mon, 7 Jan 2013 09:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI5agPPK54hv for ; Mon, 7 Jan 2013 09:10:51 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3B52D21F861A for ; Mon, 7 Jan 2013 09:10:50 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TsGDp-00023C-Dq; Mon, 07 Jan 2013 12:10:49 -0500 Message-ID: <50EB0197.5070403@computer.org> Date: Mon, 07 Jan 2013 09:10:47 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> <50EA954E.802@fkie.fraunhofer.de> In-Reply-To: <50EA954E.802@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad868d8132c3c07e3807e14ac3a28d515396350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:10:52 -0000 Hello Henning, > > Not sure SMF would apply to all of AODV anyways. SMF is for flooding a > message over the whole MANET, but some AODV messages are modified for > each hop. My conclusion is that SMF-based duplicate detection basically does not apply, and to make it apply would require some really extensive changes to AODVv2. However, the techniques for building a multicast backbone do apply. If needed, I could write another document detailing the integration of dominating-set maintenance with AODVv2. It could be done without any changes, or (alternatively) there could be integration with RERR functions. -- Regards, Charlie P. From ulrich@herberg.name Mon Jan 7 19:41:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F421F86D4 for ; Mon, 7 Jan 2013 19:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyU1TJI0208T for ; Mon, 7 Jan 2013 19:41:00 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6221D11E8099 for ; Mon, 7 Jan 2013 19:41:00 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so8659363vbb.37 for ; Mon, 07 Jan 2013 19:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=U2fRhS5cJR4/i97+dkkTnis4yoUVvVbA9IHUMHFaYAg=; b=UV4qMuDoEQPSenxk9cPQMti7Y3JWC2Z3Gz6S4bih0TMDvo62c7AEJ/OMS72KS26kcq qPfJiHQG3qJqZ28r+X1PT6nzX4Mtv8hhBBL+jCPxxt5jLWPzVRYmRnH5Lc4lv5oMSMbK rKSCRaWvvZXSpmmFR3E0PqoA/JJsp+erXRHM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=U2fRhS5cJR4/i97+dkkTnis4yoUVvVbA9IHUMHFaYAg=; b=PdNsI2LfXYjkWXWX3tscR34iVUzIMcL0MfpH3yZq574DmnsDxcDTBfAed7IGEQ58bZ KTZEk+W5/oA+hLAQrPfha2OeOjRaBJHhLx0fqf0fvLUZN/IgttqXTIGqS8Hv3kDmANuD alYCNwTsPg94YF/HK50NIsqQkgHAh69mHOSvk/rC/MpCktswkQQMXv22jsy+TJZlaaAf ASDwGxO8mcLTffGbuvlYMmh8nTwmrrS8n1zFdXz4kiNNwsaaH5oHN4rQveE6St9et2fJ 7HS+Ya2498xq3vzhR1WL0oHU1CbEcE69hs2toSowYJKGby0Bzv6INgt8qZCbvKTWZWuJ d4Dw== MIME-Version: 1.0 Received: by 10.52.66.51 with SMTP id c19mr50600239vdt.123.1357616459417; Mon, 07 Jan 2013 19:40:59 -0800 (PST) Received: by 10.220.249.72 with HTTP; Mon, 7 Jan 2013 19:40:59 -0800 (PST) In-Reply-To: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Mon, 7 Jan 2013 19:40:59 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf3071ce3ece091204d2beb62e X-Gm-Message-State: ALoCoQmJIl2UBUUR/UeYsbZyrnbK5UHJ7pL8xNjPV8a/f5FeZDnK1r2Ai2YXdO8bXYo4gLewEKFc Subject: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 03:41:01 -0000 --20cf3071ce3ece091204d2beb62e Content-Type: text/plain; charset=ISO-8859-1 Hi, we have submitted a new revision of LOADng. Here is a summary of the changes: - many editorial improvements - better characterization of applicability of LOADng (describing the constraints/traffic flows etc. instead of listing a number of use cases) - some parameters that have been router parameters are now interface parameters, which allows for using different settings for different interface types - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for allowing extensions as companion document, e.g. expanding ring search) - RERR also includes the originator address - definition of a FLAGS TLV instead of the ackrequired TLV - pre-allocation of two metrics in the IANA registries Best regards Ulrich ---------- Forwarded message ---------- From: Date: Mon, Jan 7, 2013 at 7:33 PM Subject: New Version Notification for draft-clausen-lln-loadng-07.txt To: ulrich@herberg.name Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, charliep@computer.org, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com, yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil A new version of I-D, draft-clausen-lln-loadng-07.txt has been successfully submitted by Ulrich Herberg and posted to the IETF repository. Filename: draft-clausen-lln-loadng Revision: 07 Title: The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) Creation date: 2013-01-07 WG ID: Individual Submission Number of pages: 67 URL: http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt Status: http://datatracker.ietf.org/doc/draft-clausen-lln-loadng Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07 Abstract: This document describes the Lightweight Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). The IETF Secretariat --20cf3071ce3ece091204d2beb62e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

we have submitted a new revision of LOADng. Here is a summary of= the changes:

- many editorial improvements
- better characteriza= tion of applicability of LOADng (describing the constraints/traffic flows e= tc. instead of listing a number of use cases)
- some parameters that have been router parameters are now interface parame= ters, which allows for using different settings for different interface typ= es
- RREQ/RREP/RERR include hop-limit for scope limitations (mostly for = allowing extensions as companion document, e.g. expanding ring search)
- RERR also includes the originator address
- definition of a FLAGS TLV = instead of the ackrequired TLV
- pre-allocation of two metrics in the IA= NA registries

Best regards
Ulrich

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Jan 7, 2013 at 7:33 P= M
Subject: New Version Notification for draft-clausen-lln-loadng-07.txt
To= : ulrich@herberg.name
Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, charliep@computer.org, cedri= c-2.lavenu@edf.fr, afshi= n.niktash@maxim-ic.com, yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil



A new version of I-D, draft-clausen-lln-loadng-07.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-clausen-lln-loadng
Revision: =A0 =A0 =A0 =A007
Title: =A0 =A0 =A0 =A0 =A0 The Lightweight On-demand Ad hoc Distance-vector= Routing Protocol - Next Generation (LOADng)
Creation date: =A0 2013-01-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 67
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/int= ernet-drafts/draft-clausen-lln-loadng-07.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draf= t-clausen-lln-loadng
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-clausen= -lln-loadng-07
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?= url2=3Ddraft-clausen-lln-loadng-07

Abstract:
=A0 =A0This document describes the Lightweight Ad hoc On-Demand - Next
=A0 =A0Generation (LOADng) distance vector routing protocol, a reactive
=A0 =A0routing protocol intended for use in Mobile Ad hoc NETworks (MANETs)= .




The IETF Secretariat


--20cf3071ce3ece091204d2beb62e-- From ulrich@herberg.name Mon Jan 7 19:41:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230111E80B8 for ; Mon, 7 Jan 2013 19:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W15fHMOUKmRk for ; Mon, 7 Jan 2013 19:41:37 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 41E1B21F86D4 for ; Mon, 7 Jan 2013 19:41:37 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id r6so20349799vbi.36 for ; Mon, 07 Jan 2013 19:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lWKbgKKC2QlNyh0/XF54SQNDv0NraqNc0WXQfvMOCu0=; b=d6XQ3RA2O4ubJmweiScz5prdHF5cCyKvR6TPB39k/R5kxzFoXs2wihWnvgr5GjlsFP xv9oMwtMMEIExkB06j1ngpxi9QRLvF+ErZuTv0r9uk6cTQa7FLZMUWr7NoJ8C7rhxpNz UTYCHNyl7aH+tKVANcCXYTyce0XlAVKs1pMEs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lWKbgKKC2QlNyh0/XF54SQNDv0NraqNc0WXQfvMOCu0=; b=Wp3qyFZxcWq+8qxCHdBwXW2wNpSSVdHw46a3QCSUYMyS1IKBJ3If58ZlcNN5G4iF+O MGc9Nadoxd6JZ39Y1R9dUneROvQ4m/vpWEatRV7sIG6ymnCWvrHatb/Q0cFMXzVjo9EC IZr+bOJ7AQWKf5NLr24MoroanA3Kw2njXMXE/iPma5RGFm9VzSjmxKHaN5uGJgffPW4Y e0BuQXFjYt/2a+n2+AnB7mpNltAx65wEZrUWA/LTE6v9dJhFU7JQsAJIh0BwiQhRhdSX 975If2VoTm0x5/yhe3yfYuhTVLRMVnZz5Tma+N1uJQQBkh2Vmba0vmjvLGkp8CkT8IDT FAZQ== MIME-Version: 1.0 Received: by 10.52.88.33 with SMTP id bd1mr73610367vdb.70.1357616496680; Mon, 07 Jan 2013 19:41:36 -0800 (PST) Received: by 10.220.249.72 with HTTP; Mon, 7 Jan 2013 19:41:36 -0800 (PST) In-Reply-To: <20130107215052.26500.1897.idtracker@ietfa.amsl.com> References: <20130107215052.26500.1897.idtracker@ietfa.amsl.com> Date: Mon, 7 Jan 2013 19:41:36 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec50162eb06a0b904d2beb977 X-Gm-Message-State: ALoCoQn2V2odbAIVeI/iGEFq1EIxOr/QGZ3XYAnHh/SWH4y+xP7uPH++WLKIheujcUQau/fz3QvN Subject: [manet] Fwd: New Version Notification for draft-herberg-lln-loadng-mib-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 03:41:38 -0000 --bcaec50162eb06a0b904d2beb977 Content-Type: text/plain; charset=ISO-8859-1 We have also updated the LOADng-MIB document: ---------- Forwarded message ---------- From: Date: Mon, Jan 7, 2013 at 1:50 PM Subject: New Version Notification for draft-herberg-lln-loadng-mib-02.txt To: ulrich@herberg.name Cc: robert.g.cole@us.army.mil, t.clausen@computer.org A new version of I-D, draft-herberg-lln-loadng-mib-02.txt has been successfully submitted by Ulrich Herberg and posted to the IETF repository. Filename: draft-herberg-lln-loadng-mib Revision: 02 Title: Definition of Managed Objects for the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) Creation date: 2013-01-07 WG ID: Individual Submission Number of pages: 43 URL: http://www.ietf.org/internet-drafts/draft-herberg-lln-loadng-mib-02.txt Status: http://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib Htmlized: http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-herberg-lln-loadng-mib-02 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) process on a router. The MIB module defined in this memo, denoted LOADng-MIB, also reports state. While LOADng is layer agnostic and can be run with different address families (e.g., on L2 using MAC addreses, or on L3 using IP addresss), this MIB module assumes that LOADng is used on L3, and uses only IPv4/IPv6 addresses. The IETF Secretariat --bcaec50162eb06a0b904d2beb977 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We have also updated the LOADng-MIB document:

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan 7, 2013 at 1:50 PM
Subject: New Version Notification for = draft-herberg-lln-loadng-mib-02.txt
To: ulrich@herberg.name
Cc: robert.g.cole@us.army.mil, t.clausen@computer.org



A new version of I-D, draft-herberg-lln-loadng-mib-02.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-herberg-lln-loadng-mib
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Definition of Managed Objects for the Lightweigh= t On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOAD= ng)
Creation date: =A0 2013-01-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 43
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org= /internet-drafts/draft-herberg-lln-loadng-mib-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/= draft-herberg-lln-loadng-mib
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-her= berg-lln-loadng-mib-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcd= iff?url2=3Ddraft-herberg-lln-loadng-mib-02

Abstract:
=A0 =A0This memo defines a portion of the Management Information Base (MIB)=
=A0 =A0for use with network management protocols in the Internet community.=
=A0 =A0In particular, it describes objects for configuring parameters of th= e
=A0 =A0Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next=
=A0 =A0Generation (LOADng) process on a router. =A0The MIB module defined i= n
=A0 =A0this memo, denoted LOADng-MIB, also reports state. =A0While LOADng i= s
=A0 =A0layer agnostic and can be run with different address families (e.g.,=
=A0 =A0on L2 using MAC addreses, or on L3 using IP addresss), this MIB
=A0 =A0module assumes that LOADng is used on L3, and uses only IPv4/IPv6 =A0 =A0addresses.




The IETF Secretariat


--bcaec50162eb06a0b904d2beb977-- From henning.rogge@fkie.fraunhofer.de Mon Jan 7 22:25:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E7521F8782 for ; Mon, 7 Jan 2013 22:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXDVSfnerqvH for ; Mon, 7 Jan 2013 22:25:16 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3D21F84E8 for ; Mon, 7 Jan 2013 22:25:15 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TsSca-00015S-QX; Tue, 08 Jan 2013 07:25:12 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TsSca-0000mh-Nr; Tue, 08 Jan 2013 07:25:12 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 8 Jan 2013 07:25:12 +0100 Message-ID: <50EBBBC1.6000501@fkie.fraunhofer.de> Date: Tue, 8 Jan 2013 07:25:05 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> <50EA954E.802@fkie.fraunhofer.de> <50EB0197.5070403@computer.org> In-Reply-To: <50EB0197.5070403@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080307070905000501000100" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16440/Tue Jan 8 06:40:58 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Cc: manet@ietf.org Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 06:25:17 -0000 --------------ms080307070905000501000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/07/2013 06:10 PM, Charles E. Perkins wrote: >> Not sure SMF would apply to all of AODV anyways. SMF is for flooding a= >> message over the whole MANET, but some AODV messages are modified for >> each hop. > > My conclusion is that SMF-based duplicate detection basically does not > apply, and to make it apply would require some really extensive changes= > to AODVv2. > > However, the techniques for building a multicast backbone do apply. > If needed, I could write another document detailing the integration > of dominating-set maintenance with AODVv2. It could be done without > any changes, or (alternatively) there could be integration with RERR > functions. Yes, the MPR-based flooding could work for AODV too, as long as you do=20 not expect the intermediate nodes to change the messages (except for=20 hopcount/hoplimit). But wouldn't this mean you need to run a proactive neighbor discovery=20 like NHDP ? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080307070905000501000100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMDgwNjI1MTBaMCMGCSqGSIb3DQEJBDEWBBSIppYG235DrIw+HuKBNkGPP8JU3DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAMaLta+mBRu2SzdNen6tXMtolr8aCuHpcKzcE3FHBiGS3 hpr9OIQOwZmPsC4NgnO01c7n9cbcJKugE3xDh9USL88eaxrJWwOgkbEd0f7RgUcTgm4jVNPy TnDH+BGNVl5E3lP8/VB8kpYerKO2+T5e0MzGVSn7jUGap1TmRIJMC5WvcWaptlb7Q9s1YAKF 770jqBwooTD83utlHuPuYhoWY1rFAfh+CQlOewoXXrE9m7bKnOVwtV5xUf7alUoLWOHgaf5e 4HLAo6MLDnxhwyCbLxngmAMRMav8Lw4UuSRWOqYVd9A9b3ZvbOozWGIn1jFCAX1EeOAfa4HA YoIhCSpbJwAAAAAAAA== --------------ms080307070905000501000100-- From abdussalambaryun@gmail.com Tue Jan 8 04:11:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D388021F843D for ; Tue, 8 Jan 2013 04:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EItd8hgCFWOO for ; Tue, 8 Jan 2013 04:11:54 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 11BDA21F8203 for ; Tue, 8 Jan 2013 04:11:53 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id fo13so280539vcb.7 for ; Tue, 08 Jan 2013 04:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V0RySAGYDfmfbJNhv7mFgeyEFBjogo1W1Kv9dJttCJc=; b=kU26qGuYA7saCXlMBDYqzI3LSjUGrwuy+6XzYfyNKcQr3xE4yCgfwiCp78sg/MxNwB zcET9y7C+BD+ozmgFrc5/Me0NEEpv83vpM3ZkEN2v1KeLJ8wQ0lQ85X1s7vKlYcPmO9+ zWQAbCbX9kkiOvlqt6Cprc2ZAF21z2HUNVYVMu4uz2CH2X22iIktcZgkqUqcejIxH5v/ 8OTi0zpnJAbvb6TbvYmICMWSys217Z3yqSVKnea5v2IA3XRLxfet7ne2dZA/JC20IUpp kZt+y4VrPSnNvxUpAae/0m1a2TahaFQsH2WSz62UTEQCmDRUGCJU2JooxWJ+D3fZuiu/ SdXA== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr74141388vdc.125.1357647107493; Tue, 08 Jan 2013 04:11:47 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 8 Jan 2013 04:11:47 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 13:11:47 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 12:11:55 -0000 Hi Herberg, You did not involve us or me in the work of amending your work, how can I review it while you did not ask for my opinion in the first place. I was interested to join the work after you presented the work to MANET WG and I asked questions but no one likes to reply, now you want me to review and reply, how can this happen. Please talk us through the work you done so I can know what is happend. Please note that working alone is not the practice of IETF, if I understand the practice of WG well. I look forward to review the new draft after you explain to me what is my position am I just review our private work without I know what was discussed outside the IETF, or is my position ok I will tell you every thing you need to know, and please review my work and suggest your ideas. Please note that I am lost, to understand the situation with this draft, even though I know that the WG have accepted to discuss the work, but don't see that the authors accepted to join us into their discussions. Thanking you for updating the you work in IETF, Take care, AB On 1/8/13, Ulrich Herberg wrote: > Hi, > > we have submitted a new revision of LOADng. Here is a summary of the > changes: > > - many editorial improvements > - better characterization of applicability of LOADng (describing the > constraints/traffic flows etc. instead of listing a number of use cases) > - some parameters that have been router parameters are now interface > parameters, which allows for using different settings for different > interface types > - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for > allowing extensions as companion document, e.g. expanding ring search) > - RERR also includes the originator address > - definition of a FLAGS TLV instead of the ackrequired TLV > - pre-allocation of two metrics in the IANA registries > > Best regards > Ulrich > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 7, 2013 at 7:33 PM > Subject: New Version Notification for draft-clausen-lln-loadng-07.txt > To: ulrich@herberg.name > Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, > charliep@computer.org, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com, > yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, > hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil > > > > A new version of I-D, draft-clausen-lln-loadng-07.txt > has been successfully submitted by Ulrich Herberg and posted to the > IETF repository. > > Filename: draft-clausen-lln-loadng > Revision: 07 > Title: The Lightweight On-demand Ad hoc Distance-vector Routing > Protocol - Next Generation (LOADng) > Creation date: 2013-01-07 > WG ID: Individual Submission > Number of pages: 67 > URL: > http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt > Status: http://datatracker.ietf.org/doc/draft-clausen-lln-loadng > Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-07 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07 > > Abstract: > This document describes the Lightweight Ad hoc On-Demand - Next > Generation (LOADng) distance vector routing protocol, a reactive > routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). > > > > > The IETF Secretariat > From yi.jiazi@gmail.com Tue Jan 8 04:51:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7695621F8B06 for ; Tue, 8 Jan 2013 04:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka5ewf6yNqdO for ; Tue, 8 Jan 2013 04:51:32 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0A10A21F8AE7 for ; Tue, 8 Jan 2013 04:51:31 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id je9so218025bkc.27 for ; Tue, 08 Jan 2013 04:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=Rvxboa0NYy9A1n6VsEFHuaVeJB/FH5obNd1T59jr2vE=; b=VJOv5VJ+xlq8YO5+X/BqSw+ge7/AddRXsIM/mwfNqCAZkZ3Afcd3jV0K+NNlIdHJJ3 8djxMc/Ig0KrKYgKwhMKIB0mQjUEdaTFnSOxEhzvoOOn3AbUhZd/Mbhu5qnFAt+uPgP9 BhGIWgcahRKDXBWampqoDjxWDXWTixVRKIAY/vC3rSFCfUdiB9qf/I2LnexLCWeG9uxs dQgNJhSONxQncIbK5L9aSIEZQi4/qFsbxBznvP46qjHYqlcWFRLUc2ygBTvqQUNj4chx 1Wcv3gXByTAwCwiE9n72FQD0tT5erUyHTO8lBVYcVvsrejY6hz5JuC5bscZ6LawUjH8S maug== X-Received: by 10.204.5.205 with SMTP id 13mr32704406bkw.111.1357649490612; Tue, 08 Jan 2013 04:51:30 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id m20sm45252387bkw.4.2013.01.08.04.51.29 (version=SSLv3 cipher=OTHER); Tue, 08 Jan 2013 04:51:29 -0800 (PST) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_059B83C8-FD2C-4D43-88D2-FBB8AF6AF82D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Tue, 8 Jan 2013 13:51:27 +0100 Message-Id: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 12:51:33 -0000 --Apple-Mail=_059B83C8-FD2C-4D43-88D2-FBB8AF6AF82D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi AB,=20 LOADng is certainly not working alone. There are 10~ authors of it, = providing significant improvements in each new revision, which are based = on the feedback from the working group and problems we encountered in = the tests.=20 As far as I can see, the LOADng authors participated actively in those = technical discussions. For other issues, WG chairs and AD have already = briefed them, and I don't want to repeat here.=20 I'm not sure that I understood what you are trying to say in your second = paragraph with my crappy English, but I can't agree that "don't see = that the (LOADng) authors accepted to join us into their discussions." = Everyone is welcome to give comments to the document, and LOADng authors = are looking forward to discuss them.=20 best Jiazi On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun = wrote: > Hi Herberg, >=20 > You did not involve us or me in the work of amending your work, how > can I review it while you did not ask for my opinion in the first > place. I was interested to join the work after you presented the work > to MANET WG and I asked questions but no one likes to reply, now you > want me to review and reply, how can this happen. Please talk us > through the work you done so I can know what is happend. Please note > that working alone is not the practice of IETF, if I understand the > practice of WG well. >=20 > I look forward to review the new draft after you explain to me what is > my position am I just review our private work without I know what was > discussed outside the IETF, or is my position ok I will tell you every > thing you need to know, and please review my work and suggest your > ideas. Please note that I am lost, to understand the situation with > this draft, even though I know that the WG have accepted to discuss > the work, but don't see that the authors accepted to join us into > their discussions. >=20 > Thanking you for updating the you work in IETF, >=20 > Take care, > AB >=20 > On 1/8/13, Ulrich Herberg wrote: >> Hi, >>=20 >> we have submitted a new revision of LOADng. Here is a summary of the >> changes: >>=20 >> - many editorial improvements >> - better characterization of applicability of LOADng (describing the >> constraints/traffic flows etc. instead of listing a number of use = cases) >> - some parameters that have been router parameters are now interface >> parameters, which allows for using different settings for different >> interface types >> - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for >> allowing extensions as companion document, e.g. expanding ring = search) >> - RERR also includes the originator address >> - definition of a FLAGS TLV instead of the ackrequired TLV >> - pre-allocation of two metrics in the IANA registries >>=20 >> Best regards >> Ulrich >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Jan 7, 2013 at 7:33 PM >> Subject: New Version Notification for draft-clausen-lln-loadng-07.txt >> To: ulrich@herberg.name >> Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, >> charliep@computer.org, cedric-2.lavenu@edf.fr, = afshin.niktash@maxim-ic.com, >> yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, >> hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil >>=20 >>=20 >>=20 >> A new version of I-D, draft-clausen-lln-loadng-07.txt >> has been successfully submitted by Ulrich Herberg and posted to the >> IETF repository. >>=20 >> Filename: draft-clausen-lln-loadng >> Revision: 07 >> Title: The Lightweight On-demand Ad hoc Distance-vector = Routing >> Protocol - Next Generation (LOADng) >> Creation date: 2013-01-07 >> WG ID: Individual Submission >> Number of pages: 67 >> URL: >> http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt >> Status: = http://datatracker.ietf.org/doc/draft-clausen-lln-loadng >> Htmlized: = http://tools.ietf.org/html/draft-clausen-lln-loadng-07 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-clausen-lln-loadng-07 >>=20 >> Abstract: >> This document describes the Lightweight Ad hoc On-Demand - Next >> Generation (LOADng) distance vector routing protocol, a reactive >> routing protocol intended for use in Mobile Ad hoc NETworks = (MANETs). >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_059B83C8-FD2C-4D43-88D2-FBB8AF6AF82D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = AB, 
As = far as I can see, the LOADng authors participated actively in those = technical discussions. For other issues, WG chairs and AD have already = briefed them, and I don't want to repeat here. 
I'm not sure that I = understood what you are trying to say in your second paragraph with my = crappy English, but I can't agree that  "don't see that the = (LOADng) authors accepted to join us into their discussions." = Everyone is welcome to give comments to the document, and LOADng authors = are looking forward to discuss them. 


Jiazi
On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

Hi Herberg,

You did not involve us or me in the = work of amending your work, how
can I review it while you did not ask = for my opinion in the first
place. I was interested to join the work = after you presented the work
to MANET WG and I asked questions but no = one likes to reply, now you
want me to review and reply, how can this = happen. Please talk us
through the work you done so I can know what = is happend. Please note
that working alone is not the practice of = IETF, if I understand the
practice of WG well.

I look forward = to review the new draft after you explain to me what is
my position = am I just review our private work without I know what was
discussed = outside the IETF, or is my position ok I will tell you every
thing = you need to know, and please review my work and suggest your
ideas. = Please note that I am lost, to understand the situation with
this = draft, even though I know that the WG have accepted to discuss
the = work, but don't see that the authors accepted to join us into
their = discussions.

Thanking you for updating the you work in = IETF,

Take care,
AB

On 1/8/13, Ulrich Herberg <ulrich@herberg.name> = wrote:
Hi,

we have submitted a new = revision of LOADng. Here is a summary of the
changes:

- many = editorial improvements
- better characterization of applicability of = LOADng (describing the
constraints/traffic flows etc. instead of = listing a number of use cases)
- some parameters that have been = router parameters are now interface
parameters, which allows for = using different settings for different
interface types
- = RREQ/RREP/RERR include hop-limit for scope limitations (mostly = for
allowing extensions as companion document, e.g. expanding ring = search)
- RERR also includes the originator address
- definition = of a FLAGS TLV instead of the ackrequired TLV
- pre-allocation of two = metrics in the IANA registries

Best = regards
Ulrich

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org><= br>Date: Mon, Jan 7, 2013 at 7:33 PM
Subject: New Version = Notification for draft-clausen-lln-loadng-07.txt
To: ulrich@herberg.name
Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org,
charliep@computer.org, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com,
yuichi.igarashi.hb@hitachi.= com, thierry.lys@erdfdistributi= on.fr,
hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil

<= br>
A new version of I-D, draft-clausen-lln-loadng-07.txt
has been = successfully submitted by Ulrich Herberg and posted to the
IETF = repository.

Filename: =        draft-clausen-lln-loadng
Revi= sion:        07
Title: =           The = Lightweight On-demand Ad hoc Distance-vector Routing
Protocol - Next = Generation (LOADng)
Creation date:   2013-01-07
WG ID: =           Individual = Submission
Number of pages: 67
URL:
http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt=
Status: =          http://datatracker.i= etf.org/doc/draft-clausen-lln-loadng
Htmlized: =        http://tools.ietf.org/html/draft= -clausen-lln-loadng-07
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraf= t-clausen-lln-loadng-07

Abstract:
  This document = describes the Lightweight Ad hoc On-Demand - Next
=   Generation (LOADng) distance vector routing protocol, a = reactive
  routing protocol intended for use in Mobile Ad = hoc NETworks (MANETs).




The IETF = Secretariat

__________________________________________= _____
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_059B83C8-FD2C-4D43-88D2-FBB8AF6AF82D-- From abdussalambaryun@gmail.com Tue Jan 8 06:01:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBFF21F8937 for ; Tue, 8 Jan 2013 06:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1CvlgzmC5Os for ; Tue, 8 Jan 2013 06:01:41 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id E5ACE21F88C8 for ; Tue, 8 Jan 2013 06:01:40 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id n11so399336vch.30 for ; Tue, 08 Jan 2013 06:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yj7arnwEiohthrBrchFdhYFMHiTETke3ZCi/x8Mup1k=; b=Z1i8not1jVKNNMher4Wmf1sKJResgbQL3Vp6ooAJTgbgT+/f00w0vxfSJ6Cet7feGx wjctj6Y0UkIc9e/9D+nQphvWLKoS99Nd6/yn7nQ/GY/Oxx2Tq8VV7GozOFgu/Extj9l6 jyJ5EDAST00S8wfa1PtA7fo3SxL/rfpBybRy7RTjqGSjIlLbkObBQwUSr5dw3uyMeaA+ EXjhJxGoipLIpw3Yi4GW4BHl7Qa75/BgyyijT5linWhbjnNBe4nUIENk27rB9YSqyQTD B1+Fqluw4n42ngT+vUn7m3SW8HBuKb6JsitXQ1cYCRrQ2tk1+dHqHW4a+7Xe1wrmu5V9 pIhA== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr86695214vco.22.1357653700305; Tue, 08 Jan 2013 06:01:40 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 8 Jan 2013 06:01:40 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 15:01:40 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:01:42 -0000 Hi Jiazi, I thank you for reply, I need to know how to participate in such work, I was promissed before by some authors of replying to some quest but they did not take it serious, comments inline; On 1/8/13, Jiazi Yi wrote: > Hi AB, > > LOADng is certainly not working alone. There are 10~ authors of it, > providing significant improvements in each new revision, which are based on > the feedback from the working group and problems we encountered in the > tests. I always believe that authors are same as a one author alone. So you confirm that the 10 authors cooperate and discuss the work through, but am I able to ask questions as why an input was changed from previous draft? if yes, then I will be happy to review, otherwise, I will be lost or ignored from the process, > As far as I can see, the LOADng authors participated actively in those > technical discussions. For other issues, WG chairs and AD have already > briefed them, and I don't want to repeat here. I respect your viewes but it seems I had another point of view regarding my situation with this work, because I am not an author, > > I'm not sure that I understood what you are trying to say in your second > paragraph with my crappy English, but I can't agree that "don't see that To explain the paragraph you missed is : a question as, Will any volunteering effort input/review be respected to get a knowledge reply/respond. > the (LOADng) authors accepted to join us into their discussions." Everyone > is welcome to give comments to the document, and LOADng authors are looking > forward to discuss them. What about the authors' input/change/update hope they are welling to discuss their input into our WG, not only my/any comment about such input? However, your reply seems to agree that there is welling to discuss, which I will try to assume from now, Regards AB > On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun > wrote: > >> Hi Herberg, >> >> You did not involve us or me in the work of amending your work, how >> can I review it while you did not ask for my opinion in the first >> place. I was interested to join the work after you presented the work >> to MANET WG and I asked questions but no one likes to reply, now you >> want me to review and reply, how can this happen. Please talk us >> through the work you done so I can know what is happend. Please note >> that working alone is not the practice of IETF, if I understand the >> practice of WG well. >> >> I look forward to review the new draft after you explain to me what is >> my position am I just review our private work without I know what was >> discussed outside the IETF, or is my position ok I will tell you every >> thing you need to know, and please review my work and suggest your >> ideas. Please note that I am lost, to understand the situation with >> this draft, even though I know that the WG have accepted to discuss >> the work, but don't see that the authors accepted to join us into >> their discussions. >> >> Thanking you for updating the you work in IETF, >> >> Take care, >> AB >> >> On 1/8/13, Ulrich Herberg wrote: >>> Hi, >>> >>> we have submitted a new revision of LOADng. Here is a summary of the >>> changes: >>> >>> - many editorial improvements >>> - better characterization of applicability of LOADng (describing the >>> constraints/traffic flows etc. instead of listing a number of use cases) >>> - some parameters that have been router parameters are now interface >>> parameters, which allows for using different settings for different >>> interface types >>> - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for >>> allowing extensions as companion document, e.g. expanding ring search) >>> - RERR also includes the originator address >>> - definition of a FLAGS TLV instead of the ackrequired TLV >>> - pre-allocation of two metrics in the IANA registries >>> >>> Best regards >>> Ulrich >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, Jan 7, 2013 at 7:33 PM >>> Subject: New Version Notification for draft-clausen-lln-loadng-07.txt >>> To: ulrich@herberg.name >>> Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, >>> charliep@computer.org, cedric-2.lavenu@edf.fr, >>> afshin.niktash@maxim-ic.com, >>> yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, >>> hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil >>> >>> >>> >>> A new version of I-D, draft-clausen-lln-loadng-07.txt >>> has been successfully submitted by Ulrich Herberg and posted to the >>> IETF repository. >>> >>> Filename: draft-clausen-lln-loadng >>> Revision: 07 >>> Title: The Lightweight On-demand Ad hoc Distance-vector >>> Routing >>> Protocol - Next Generation (LOADng) >>> Creation date: 2013-01-07 >>> WG ID: Individual Submission >>> Number of pages: 67 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-clausen-lln-loadng >>> Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-07 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07 >>> >>> Abstract: >>> This document describes the Lightweight Ad hoc On-Demand - Next >>> Generation (LOADng) distance vector routing protocol, a reactive >>> routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). >>> >>> >>> >>> >>> The IETF Secretariat >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Tue Jan 8 06:12:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9E21F84D8 for ; Tue, 8 Jan 2013 06:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37HSHQ-2MzUo for ; Tue, 8 Jan 2013 06:12:03 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 81B1521F844C for ; Tue, 8 Jan 2013 06:12:02 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id ez10so406544vbb.11 for ; Tue, 08 Jan 2013 06:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Cvq3hmnTYHglRbjbLj41qFLF7fRwdbKHLo0/zSpCrk=; b=ZUavU+P7jpqXEM6sxUnRsn7TwdXNwIbgNNfd6mkFNdqMK6ONeJfF7AzojpmqSk+1R3 EOrfLWWrOjT/uxijusFNdo1FnA5jm2oFQ0nl+GV+RoHVdemLKWsFiNbaoyzERk9iTjs3 szp9Eu/uGuIWG8PSdl9qpb+BPZygTRsuHJzVyfLL1Ppu/yw5o2yJKRoPQkUgunF460WC T6tHD/1ZPaDhPlYn8phrEOLiMxidDpL1MNfjRguODbYF9ZypsJVH5X4Bo95kYifyYR8Z Zu1BzvlASOQzBJ9dwvbjEetqBA33Quv8C1/HxxpH+tuIc8vgAGblbp/E959oJy8KM++H GYZw== MIME-Version: 1.0 Received: by 10.58.31.200 with SMTP id c8mr6000889vei.23.1357654321905; Tue, 08 Jan 2013 06:12:01 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 8 Jan 2013 06:12:01 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 15:12:01 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:12:04 -0000 Hi Jiazi and Herberg, Please answer my questions below: > - better characterization of applicability of LOADng (describing the > constraints/traffic flows etc. instead of listing a number of use cases) Is it ok if you give at least one example use case, please reply? > - some parameters that have been router parameters are now interface > parameters, which allows for using different settings for different > interface types Do you mean ALL router parameters or MOST router parameters are now interface parameters? Is this a MUST for the protocol or a SHOULD? , please reply? Best Regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++ Note: If this message not replied by any author, it will be sent to the AD to get a response from the authors. +++++++++++++++++++++++++ From jvasseur@cisco.com Tue Jan 8 07:10:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7636821F848B for ; Tue, 8 Jan 2013 07:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j77oHNA10vy0 for ; Tue, 8 Jan 2013 07:10:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5121F846E for ; Tue, 8 Jan 2013 07:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17580; q=dns/txt; s=iport; t=1357657857; x=1358867457; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9+jkFtl9WObz30gy7ZrQWzZ5pB0yQdhJJxF05dZLfBU=; b=H4Jax1Y6gEcMauPEui6Je6nhY5PDlhQ0qdRxtp+g9iSNzplUSoXdevyb noB6jEzizW05Yb3KDahy9CtsMyUXUQMzZ0qiPSXlkwVv9Bj9zY/4u5Jye SMgNYabx0W+hhJfX+9wz5bqYz1mN25Q4YSjskFehZvCQDp0XOozMvGhWE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYGAHQ27FCtJV2Y/2dsb2JhbABEg2yFLKISiQwBhlWCTRZzgh4BAQEEAQEBawkCEAIBCA4DAwECCx0HIQYLFAkIAgQOBQgBh3wDDwcFqSuGWw2GVYtogQCDTGEDlDaCcoobhRKCdIFpPQ X-IronPort-AV: E=Sophos;i="4.84,432,1355097600"; d="scan'208,217";a="157077358" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jan 2013 15:10:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r08FAunN027140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 15:10:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.7]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 09:10:56 -0600 From: "JP Vasseur (jvasseur)" To: Jiazi Yi Thread-Topic: [manet] New Version Notification for draft-clausen-lln-loadng-07.txt Thread-Index: AQHN7bJb9ac4blYjBkmDRTz5dKonYQ== Date: Tue, 8 Jan 2013 15:10:55 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77231BFB0A@xmb-rcd-x02.cisco.com> References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.230] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77231BFB0Axmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:10:59 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77231BFB0Axmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jiazi, I think that the frustration is coming from the fact that this I-D not bein= g a WG document, it "belongs" to their authors, and the process by which you make changes is opaque. Changes may come from experiments, fie= ld trials, =85 but without background, it is difficult indeed to understand the rationale for this changes, improvements, =85 Let'= s see if at some point we get one WG document, being *the* WG document, that will be subject to discussion with the participation of t= he entire WG. Thanks. JP. On Jan 8, 2013, at 1:51 PM, Jiazi Yi wrote: Hi AB, LOADng is certainly not working alone. There are 10~ authors of it, provid= ing significant improvements in each new revision, which are based on the f= eedback from the working group and problems we encountered in the tests. As far as I can see, the LOADng authors participated actively in those tech= nical discussions. For other issues, WG chairs and AD have already briefed = them, and I don't want to repeat here. I'm not sure that I understood what you are trying to say in your second pa= ragraph with my crappy English, but I can't agree that "don't see that the= (LOADng) authors accepted to join us into their discussions." Everyone is = welcome to give comments to the document, and LOADng authors are looking fo= rward to discuss them. best Jiazi On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun > wrote: Hi Herberg, You did not involve us or me in the work of amending your work, how can I review it while you did not ask for my opinion in the first place. I was interested to join the work after you presented the work to MANET WG and I asked questions but no one likes to reply, now you want me to review and reply, how can this happen. Please talk us through the work you done so I can know what is happend. Please note that working alone is not the practice of IETF, if I understand the practice of WG well. I look forward to review the new draft after you explain to me what is my position am I just review our private work without I know what was discussed outside the IETF, or is my position ok I will tell you every thing you need to know, and please review my work and suggest your ideas. Please note that I am lost, to understand the situation with this draft, even though I know that the WG have accepted to discuss the work, but don't see that the authors accepted to join us into their discussions. Thanking you for updating the you work in IETF, Take care, AB On 1/8/13, Ulrich Herberg >= wrote: Hi, we have submitted a new revision of LOADng. Here is a summary of the changes: - many editorial improvements - better characterization of applicability of LOADng (describing the constraints/traffic flows etc. instead of listing a number of use cases) - some parameters that have been router parameters are now interface parameters, which allows for using different settings for different interface types - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for allowing extensions as companion document, e.g. expanding ring search) - RERR also includes the originator address - definition of a FLAGS TLV instead of the ackrequired TLV - pre-allocation of two metrics in the IANA registries Best regards Ulrich ---------- Forwarded message ---------- From: > Date: Mon, Jan 7, 2013 at 7:33 PM Subject: New Version Notification for draft-clausen-lln-loadng-07.txt To: ulrich@herberg.name Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, charliep@computer.org, cedric-2.lavenu@edf.fr= , afshin.niktash@maxim-ic.com, yuichi.igarashi.hb@hitachi.com, thie= rry.lys@erdfdistribution.fr, hiroki.satoh.yj@hitachi.com, jdean@itd.= nrl.navy.mil A new version of I-D, draft-clausen-lln-loadng-07.txt has been successfully submitted by Ulrich Herberg and posted to the IETF repository. Filename: draft-clausen-lln-loadng Revision: 07 Title: The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) Creation date: 2013-01-07 WG ID: Individual Submission Number of pages: 67 URL: http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt Status: http://datatracker.ietf.org/doc/draft-clausen-lln-loadng Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-clausen-lln-loadng-07 Abstract: This document describes the Lightweight Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). The IETF Secretariat _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77231BFB0Axmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4E9BD9CD34CE8347BA6011CE2CC4693C@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Jiazi,

I think that the frustration is coming from the fact that this I-D not= being a WG document, it "belongs" to their authors, and the proc= ess
by which you make changes is opaque. Changes may come from experiments= , field trials, =85 but without background, it is difficult 
indeed to understand the rationale for this changes, improvements, =85= Let's see if at some point we get one WG document, being *the* 
WG document, that will be subject to discussion with the participation= of the entire WG.

Thanks.

JP.

On Jan 8, 2013, at 1:51 PM, Jiazi Yi wrote:

Hi AB, 

LOADng is certainly not working alone. There are 10~ authors of it,  p= roviding significant improvements in each new revision, which are based on = the feedback from the working group and problems we encountered in the test= s. 

As far as I can see, the LOADng authors participated actively in those tech= nical discussions. For other issues, WG chairs and AD have already briefed = them, and I don't want to repeat here. 

I'm not sure that I understood what you are trying to say in your second pa= ragraph with my crappy English, but I can't agree that  "don= 't see that the (LOADng) authors accepted to join us into their discus= sions." Everyone is welcome to give comments to the document, and LOADng authors are looking forward to discuss them. 

best

Jiazi

On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Herberg,

You did not involve us or me in the work of amending your work, how
can I review it while you did not ask for my opinion in the first
place. I was interested to join the work after you presented the work
to MANET WG and I asked questions but no one likes to reply, now you
want me to review and reply, how can this happen. Please talk us
through the work you done so I can know what is happend. Please note
that working alone is not the practice of IETF, if I understand the
practice of WG well.

I look forward to review the new draft after you explain to me what is
my position am I just review our private work without I know what was
discussed outside the IETF, or is my position ok I will tell you every
thing you need to know, and please review my work and suggest your
ideas. Please note that I am lost, to understand the situation with
this draft, even though I know that the WG have accepted to discuss
the work, but don't see that the authors accepted to join us into
their discussions.

Thanking you for updating the you work in IETF,

Take care,
AB

On 1/8/13, Ulrich Herberg <ulrich= @herberg.name> wrote:
Hi,

we have submitted a new revision of LOADng. Here is a summary of the
changes:

- many editorial improvements
- better characterization of applicability of LOADng (describing the
constraints/traffic flows etc. instead of listing a number of use cases) - some parameters that have been router parameters are now interface
parameters, which allows for using different settings for different
interface types
- RREQ/RREP/RERR include hop-limit for scope limitations (mostly for
allowing extensions as companion document, e.g. expanding ring search)
- RERR also includes the originator address
- definition of a FLAGS TLV instead of the ackrequired TLV
- pre-allocation of two metrics in the IANA registries

Best regards
Ulrich

---------- Forwarded message ----------
From: <internet-drafts@ietf.= org>
Date: Mon, Jan 7, 2013 at 7:33 PM
Subject: New Version Notification for draft-clausen-lln-loadng-07.txt
To: ulrich@herberg.name
Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@c= omputer.org,
charliep@computer.org, cedric-2.lavenu@edf.fr, = afshin.niktash@maxim-ic.com,
yuichi.igarashi.hb@hitach= i.com, thierry.lys@erdfdistribu= tion.fr,
hiroki.satoh.yj@hitachi.com<= /a>, jdean@itd.nrl.navy.mil



A new version of I-D, draft-clausen-lln-loadng-07.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename:        draft-clausen-lln-loadn= g
Revision:        07
Title:           The Ligh= tweight On-demand Ad hoc Distance-vector Routing
Protocol - Next Generation (LOADng)
Creation date:   2013-01-07
WG ID:           Individu= al Submission
Number of pages: 67
URL:
http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt
Status:          http://datatracker.= ietf.org/doc/draft-clausen-lln-loadng
Htmlized:        http://tools.ietf.org/html/draf= t-clausen-lln-loadng-07
Diff:
= http://www.ietf.org/rfcdiff?url2=3Ddraft-clausen-lln-loadng-07

Abstract:
  This document describes the Lightweight Ad hoc On-Demand - Next=
  Generation (LOADng) distance vector routing protocol, a reactiv= e
  routing protocol intended for use in Mobile Ad hoc NETworks (MA= NETs).




The IETF Secretariat

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A77231BFB0Axmbrcdx02ciscoc_-- From charliep@computer.org Tue Jan 8 09:08:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3621F84D5 for ; Tue, 8 Jan 2013 09:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWEFAUrYtF7s for ; Tue, 8 Jan 2013 09:08:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 09A0211E80E5 for ; Tue, 8 Jan 2013 09:08:08 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tscel-0006XE-Tq; Tue, 08 Jan 2013 12:08:08 -0500 Message-ID: <50EC5274.7070809@computer.org> Date: Tue, 08 Jan 2013 09:08:04 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" , Jiazi Yi References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A77231BFB0A@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77231BFB0A@xmb-rcd-x02.cisco.com> Content-Type: multipart/alternative; boundary="------------010805090607040207090603" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866d0824de80f0d30e008651fd40157aaf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet Subject: Re: [manet] New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:08:13 -0000 This is a multi-part message in MIME format. --------------010805090607040207090603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, It has been my strong wish for a long time to have a merged document. To this end, I have brought the WG document into RFC 5444 compliance, and (at request of the LOADng authors) put Intermediate RREP into a separate document. I've responded to suggestions about readability, and various other technical details. By now the WG document is in considerably better shape. Previously, the LOADng author team expressed concerns that the WG document was not (in their opinion) readable. I believe those concerns can be safely laid to rest, and if there are additional measures I can take for further improvement I will not hesitate to do so. I look forward to the discussion. LOADng properly belongs as a set of parameter and optional behavior choices for a merged WG document. By now, the merge will be quite straightforward because LOADng has become more like the WG document, and I have taken direct measures to make the WG document more adaptable to fit the needs of LOADng. Since releasing the ...-25.txt revision for the AODVv2 specification, I have noticed some typos, and as mentioned earlier there are several minor issues that, once resolved, could result in changes to the specification. I'll submit those to the list and the issue tracker today. Regards, Charlie P. On 1/8/2013 7:10 AM, JP Vasseur (jvasseur) wrote: > Hi Jiazi, > > I think that the frustration is coming from the fact that this I-D not > being a WG document, it "belongs" to their authors, and the process > by which you make changes is opaque. Changes may come from > experiments, field trials, ... but without background, it is difficult > indeed to understand the rationale for this changes, improvements, ... > Let's see if at some point we get one WG document, being *the* > WG document, that will be subject to discussion with the participation > of the entire WG. > > Thanks. > > JP. > > On Jan 8, 2013, at 1:51 PM, Jiazi Yi wrote: > >> Hi AB, >> >> LOADng is certainly not working alone. There are 10~ authors of it, >> providing significant improvements in each new revision, which are >> based on the feedback from the working group and problems we >> encountered in the tests. >> >> As far as I can see, the LOADng authors participated actively in >> those technical discussions. For other issues, WG chairs and AD have >> already briefed them, and I don't want to repeat here. >> >> I'm not sure that I understood what you are trying to say in your >> second paragraph with my crappy English, but I can't agree >> that "don't see that the (LOADng) authors accepted to join us >> into their discussions." Everyone is welcome to give comments to the >> document, and LOADng authors are looking forward to discuss them. >> >> best >> >> Jiazi >> >> On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun >> > wrote: >> >>> Hi Herberg, >>> >>> You did not involve us or me in the work of amending your work, how >>> can I review it while you did not ask for my opinion in the first >>> place. I was interested to join the work after you presented the work >>> to MANET WG and I asked questions but no one likes to reply, now you >>> want me to review and reply, how can this happen. Please talk us >>> through the work you done so I can know what is happend. Please note >>> that working alone is not the practice of IETF, if I understand the >>> practice of WG well. >>> >>> I look forward to review the new draft after you explain to me what is >>> my position am I just review our private work without I know what was >>> discussed outside the IETF, or is my position ok I will tell you every >>> thing you need to know, and please review my work and suggest your >>> ideas. Please note that I am lost, to understand the situation with >>> this draft, even though I know that the WG have accepted to discuss >>> the work, but don't see that the authors accepted to join us into >>> their discussions. >>> >>> Thanking you for updating the you work in IETF, >>> >>> Take care, >>> AB >>> >>> On 1/8/13, Ulrich Herberg >> > wrote: >>>> Hi, >>>> >>>> we have submitted a new revision of LOADng. Here is a summary of the >>>> changes: >>>> >>>> - many editorial improvements >>>> - better characterization of applicability of LOADng (describing the >>>> constraints/traffic flows etc. instead of listing a number of use >>>> cases) >>>> - some parameters that have been router parameters are now interface >>>> parameters, which allows for using different settings for different >>>> interface types >>>> - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for >>>> allowing extensions as companion document, e.g. expanding ring search) >>>> - RERR also includes the originator address >>>> - definition of a FLAGS TLV instead of the ackrequired TLV >>>> - pre-allocation of two metrics in the IANA registries >>>> >>>> Best regards >>>> Ulrich >>>> >>>> ---------- Forwarded message ---------- >>>> From: > >>>> Date: Mon, Jan 7, 2013 at 7:33 PM >>>> Subject: New Version Notification for draft-clausen-lln-loadng-07.txt >>>> To: ulrich@herberg.name >>>> Cc: jiazi@jiaziyi.com , axel@axelcdv.com >>>> , t.clausen@computer.org >>>> , >>>> charliep@computer.org , >>>> cedric-2.lavenu@edf.fr , >>>> afshin.niktash@maxim-ic.com , >>>> yuichi.igarashi.hb@hitachi.com >>>> , >>>> thierry.lys@erdfdistribution.fr >>>> , >>>> hiroki.satoh.yj@hitachi.com , >>>> jdean@itd.nrl.navy.mil >>>> >>>> >>>> >>>> A new version of I-D, draft-clausen-lln-loadng-07.txt >>>> has been successfully submitted by Ulrich Herberg and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-clausen-lln-loadng >>>> Revision: 07 >>>> Title: The Lightweight On-demand Ad hoc Distance-vector >>>> Routing >>>> Protocol - Next Generation (LOADng) >>>> Creation date: 2013-01-07 >>>> WG ID: Individual Submission >>>> Number of pages: 67 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt >>>> Status: http://datatracker.ietf.org/doc/draft-clausen-lln-loadng >>>> Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-07 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07 >>>> >>>> Abstract: >>>> This document describes the Lightweight Ad hoc On-Demand - Next >>>> Generation (LOADng) distance vector routing protocol, a reactive >>>> routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------010805090607040207090603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello folks,

It has been my strong wish for a long time to have a merged document.
To this end, I have brought the WG document into RFC 5444 compliance,
and (at request of the LOADng authors) put Intermediate RREP into a
separate document.  I've responded to suggestions about readability,
and various other technical details.

By now the WG document is in considerably better shape.

Previously, the LOADng author team expressed concerns that the WG
document was not (in their opinion) readable.  I believe those concerns
can be safely laid to rest, and if there are additional measures I can take
for further improvement I will not hesitate to do so.  I look forward to
the discussion.

LOADng properly belongs as a set of parameter and optional
behavior choices for a merged WG document.  By now, the merge will
be quite straightforward because LOADng has become more like the
WG document, and I have taken direct measures to make the WG
document more adaptable to fit the needs of LOADng.

Since releasing the ...-25.txt revision for the AODVv2 specification, I have
noticed some typos, and as mentioned earlier there are several minor
issues that, once resolved, could result in changes to the specification.
I'll submit those to the list and the issue tracker today.

Regards,
Charlie P.



On 1/8/2013 7:10 AM, JP Vasseur (jvasseur) wrote:
Hi Jiazi,

I think that the frustration is coming from the fact that this I-D not being a WG document, it "belongs" to their authors, and the process
by which you make changes is opaque. Changes may come from experiments, field trials, … but without background, it is difficult 
indeed to understand the rationale for this changes, improvements, … Let's see if at some point we get one WG document, being *the* 
WG document, that will be subject to discussion with the participation of the entire WG.

Thanks.

JP.

On Jan 8, 2013, at 1:51 PM, Jiazi Yi wrote:

Hi AB, 

LOADng is certainly not working alone. There are 10~ authors of it,  providing significant improvements in each new revision, which are based on the feedback from the working group and problems we encountered in the tests. 

As far as I can see, the LOADng authors participated actively in those technical discussions. For other issues, WG chairs and AD have already briefed them, and I don't want to repeat here. 

I'm not sure that I understood what you are trying to say in your second paragraph with my crappy English, but I can't agree that  "don't see that the (LOADng) authors accepted to join us into their discussions." Everyone is welcome to give comments to the document, and LOADng authors are looking forward to discuss them. 

best

Jiazi

On Jan 8, 2013, at 1:11 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Herberg,

You did not involve us or me in the work of amending your work, how
can I review it while you did not ask for my opinion in the first
place. I was interested to join the work after you presented the work
to MANET WG and I asked questions but no one likes to reply, now you
want me to review and reply, how can this happen. Please talk us
through the work you done so I can know what is happend. Please note
that working alone is not the practice of IETF, if I understand the
practice of WG well.

I look forward to review the new draft after you explain to me what is
my position am I just review our private work without I know what was
discussed outside the IETF, or is my position ok I will tell you every
thing you need to know, and please review my work and suggest your
ideas. Please note that I am lost, to understand the situation with
this draft, even though I know that the WG have accepted to discuss
the work, but don't see that the authors accepted to join us into
their discussions.

Thanking you for updating the you work in IETF,

Take care,
AB

On 1/8/13, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

we have submitted a new revision of LOADng. Here is a summary of the
changes:

- many editorial improvements
- better characterization of applicability of LOADng (describing the
constraints/traffic flows etc. instead of listing a number of use cases)
- some parameters that have been router parameters are now interface
parameters, which allows for using different settings for different
interface types
- RREQ/RREP/RERR include hop-limit for scope limitations (mostly for
allowing extensions as companion document, e.g. expanding ring search)
- RERR also includes the originator address
- definition of a FLAGS TLV instead of the ackrequired TLV
- pre-allocation of two metrics in the IANA registries

Best regards
Ulrich

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan 7, 2013 at 7:33 PM
Subject: New Version Notification for draft-clausen-lln-loadng-07.txt
To: ulrich@herberg.name
Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org,
charliep@computer.org, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com,
yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr,
hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil



A new version of I-D, draft-clausen-lln-loadng-07.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename:        draft-clausen-lln-loadng
Revision:        07
Title:           The Lightweight On-demand Ad hoc Distance-vector Routing
Protocol - Next Generation (LOADng)
Creation date:   2013-01-07
WG ID:           Individual Submission
Number of pages: 67
URL:
http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt
Status:          http://datatracker.ietf.org/doc/draft-clausen-lln-loadng
Htmlized:        http://tools.ietf.org/html/draft-clausen-lln-loadng-07
Diff:
http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07

Abstract:
  This document describes the Lightweight Ad hoc On-Demand - Next
  Generation (LOADng) distance vector routing protocol, a reactive
  routing protocol intended for use in Mobile Ad hoc NETworks (MANETs).




The IETF Secretariat

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------010805090607040207090603-- From ulrich@herberg.name Tue Jan 8 09:10:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC61311E80D1 for ; Tue, 8 Jan 2013 09:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohLmnpGjqB+J for ; Tue, 8 Jan 2013 09:10:22 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id A77EC11E80EF for ; Tue, 8 Jan 2013 09:10:22 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so610961vbb.24 for ; Tue, 08 Jan 2013 09:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1JAGWCX+zxT/YVMPIWzFmET/ef2fKCpspxbkcnql2/I=; b=w3DF4E7C13c2Nn0SQI5VU7G5Aba4lG040rz0e3Nh0evIEkRMAk4gEu6NOK7pU0kSjM ccGciP3Hd5NfOX7LG6HbPppssGOqR0w75rVJjPfw+Xx9SL60HwSx+7KHAcyu1Bfhylpm aAiE8UTbtmvJQOv7s5o3h0ENDeJGKo0JM1dl8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1JAGWCX+zxT/YVMPIWzFmET/ef2fKCpspxbkcnql2/I=; b=kLURebFo0A0FVdXJf9fk1OVeZO1CbHESHDcgnUx45DXTmqnEoOoVEuj0iby3c2G/sE WqN9YIBBM0WFzixf4N8Nrf8MJMEp/qg0rRUaWa8YRahTOo+Nc4rrma3CLizldceOKIYe FGi7vq9wpQZs2vC/IKbnrP1Eg1nLRW6vg2MNqVMI+dnk2XnbkGggvX7eX76i/bBqIrWZ Q4sJGVXCwasf7AZD4W1C7RdHco6rvWbT+K6G9d5qwf0NcILVlFzAcauwQbrW5JesmOwf 6oNBFTQ56RieXP3frayG3rzd6jdM/RkWPHYjTUL/QDDXjMz9thC2D4EArJ6cXqsZZkea aQOA== MIME-Version: 1.0 Received: by 10.52.88.33 with SMTP id bd1mr75203563vdb.70.1357665021890; Tue, 08 Jan 2013 09:10:21 -0800 (PST) Received: by 10.220.249.72 with HTTP; Tue, 8 Jan 2013 09:10:21 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 09:10:21 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=bcaec50162eb5a8fb804d2ca05e8 X-Gm-Message-State: ALoCoQn8+D4c7fCrK3b2aZaxTGGAms64ul2NQpQodNBXKIhwB9LgSAPin3Rh3/6IRbL02P1UOH/y Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:10:25 -0000 --bcaec50162eb5a8fb804d2ca05e8 Content-Type: text/plain; charset=ISO-8859-1 Hi Abdussalam, On Tue, Jan 8, 2013 at 6:12 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Jiazi and Herberg, > Please answer my questions below: > > > - better characterization of applicability of LOADng (describing the > > constraints/traffic flows etc. instead of listing a number of use cases) > > Is it ok if you give at least one example use case, please reply? > The rationale for the change was that rather than claiming that the protocol is useful for particular use cases, we describe the applicability of the protocol for certain network/traffic properties. This is similar to other MANET protocols we have standardized. > > > - some parameters that have been router parameters are now interface > > parameters, which allows for using different settings for different > > interface types > > Do you mean ALL router parameters or MOST router parameters are now > interface parameters? As you can easily see from the rfcdiff ( http://tools.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07.txt), not all parameters are now interface parameters, only RREQ_MAX_JITTER and USE_BIDIRECTIONAL_LINK_ONLY. MANET routers may have multiple interfaces with different properties (e.g., one wireless interface, one Ethernet interface). In such cases, it is advantageous to allow for more flexibility of the parameters per interface. > Is this a MUST for the protocol or a SHOULD? , > I don't understand that question. Best regards Ulrich > please reply? > > > > Best Regards > > Abdussalam Baryun > University of Glamorgan, UK > +++++++++++++++++++++++++ > Note: If this message not replied by any author, it will be sent to > the AD to get a response from the authors. > +++++++++++++++++++++++++ > --bcaec50162eb5a8fb804d2ca05e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Abdussalam,

On Tue, Jan 8, 2013 at 6:1= 2 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Jiazi and Herberg,=A0

Please answer my questions below:

> - better characterization of applicability of LOADng (describing the > constraints/traffic flows etc. instead of listing a number of use case= s)

Is it ok if you give at least one example use case, please reply?
=

The rationale for the change was that rather than cla= iming that the protocol is useful for particular use cases, we describe the= applicability of the protocol for certain network/traffic properties. This= is similar to other MANET protocols we have standardized.


=A0

> - some parameters that have been router parameters are now interface > parameters, which allows for using different settings for different > interface types

Do you mean ALL router parameters or MOST router parameters are now interface parameters?

As you can easily see from the r= fcdiff (http://tools.ietf.org/rfcdiff?url2=3Ddraft-clausen-lln-loadng= -07.txt), not all parameters are now interface parameters, only RREQ_MA= X_JITTER and USE_BIDIRECTIONAL_LINK_ONLY.
MANET routers may have multiple interfaces with different properties (e.g.,= one wireless interface, one Ethernet interface). In such cases, it is adva= ntageous to allow for more flexibility of the parameters per interface.


=A0
Is this a MUST for the pro= tocol or a SHOULD? ,

I don't understand that q= uestion.

Best regards
Ulrich

=A0
please reply?


=A0


Best Regards

Abdussalam Baryun
University of Glamorgan, UK
+++++++++++++++++++++++++
Note: If this message not replied by any author, it will be sent to
the AD to get a response from the authors.
+++++++++++++++++++++++++

--bcaec50162eb5a8fb804d2ca05e8-- From ulrich@herberg.name Tue Jan 8 09:41:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CC121F8506 for ; Tue, 8 Jan 2013 09:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgIQWjn9c2lX for ; Tue, 8 Jan 2013 09:41:25 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6933821F8853 for ; Tue, 8 Jan 2013 09:41:25 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id p1so653067vcq.38 for ; Tue, 08 Jan 2013 09:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=J3MkyERWQtRa4Pkp5gkTlxhTmMmgBDxVkvmGHuUD88c=; b=0BNKfMCtdQu9p0IuS18DE3TgrRBJPeiB8LfdWMjxB24f16Gg3m+Xn9QbvFzCfca72f gyinZClUcxU8/z8fDw3HFxtlZUPxAyNyYgOogSsDrOLjaqMjqQ/JdyrLKr9oyYNDmTdI Eqh3qnTvZesuOEl3enxHsTan0myeWIJwvMD4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=J3MkyERWQtRa4Pkp5gkTlxhTmMmgBDxVkvmGHuUD88c=; b=G+u0h41uChPtTLOMHqmrFmZgrXLwBCdsljSHwPm5h783loMH27/F1uCK/Gy/DdkznL kKoP0qC3DnvpPZCkRVJSsicJHxy9+dQXPtC3nWtJbYLgNMeAQxWbm4eEEG/XBt14XtPS vMvvud9YwOoDkrwy6rY2sY5JK0f5yub18iLGZmpMYxd2o4pbNQUkxu4x4GLzMXrKdINp opskFR+PXrDBMoQAxGLiCiOUKZ+kMRtsVG0E50q5gSI+ti9xKHTJ5jiGvR3TOQJe1DAZ AuBnU3eEJCrSbfqzDwmbSs6VzrKtnr1kwBXEHed5kkNJCOSzX4EdO4lhNBZt5p1769TU RfVw== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr87658865vco.22.1357666884748; Tue, 08 Jan 2013 09:41:24 -0800 (PST) Received: by 10.220.249.72 with HTTP; Tue, 8 Jan 2013 09:41:24 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 09:41:24 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7bd46385ed04d2ca7413 X-Gm-Message-State: ALoCoQndHTqC/W/1MlJCTxaK83UyJ+o1dSqmlbTdHxsFrG7Hn7S4DErZAjFeSO1qp4m6J9IRzvS2 Subject: Re: [manet] New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:41:27 -0000 --f46d043c7bd46385ed04d2ca7413 Content-Type: text/plain; charset=ISO-8859-1 Hi, as it has been requested, I will provide some rationale for the changes in the latest revision: On Mon, Jan 7, 2013 at 7:40 PM, Ulrich Herberg wrote: > Hi, > > we have submitted a new revision of LOADng. Here is a summary of the > changes: > > - many editorial improvements > The document is better to read now, and is better aligned with other WG documents / RFCs in MANET. > - better characterization of applicability of LOADng (describing the > constraints/traffic flows etc. instead of listing a number of use cases) > The rationale for the change was that rather than claiming that the protocol is useful for particular use cases, we describe the applicability of the protocol for certain network/traffic properties. This is similar to other MANET protocols we have standardized. > - some parameters that have been router parameters are now interface > parameters, which allows for using different settings for different > interface types > RREQ_MAX_JITTER and USE_BIDIRECTIONAL_LINK_ONLY are now interface parameters. MANET routers may have multiple interfaces with different properties (e.g., one wireless interface, one Ethernet interface). In such cases, it is advantageous to allow for more flexibility of the parameters per interface. RREQ_RATELIMIT has been replaced by RREQ_MIN_INTERVAL, which determines the minimum interval between two consecutive RREQs. The purpose is the same, but it is easier to implement and better aligned with other MANET RFCs. > - RREQ/RREP/RERR include hop-limit for scope limitations (mostly for > allowing extensions as companion document, e.g. expanding ring search) > As said, this allows for limiting the scope of messages. Before, we only had hop-count, which in theory could also be used to limit the scope. However, a problem arises when different routers in the MANET have different settings of MAX_HOP_COUNT; a router could receive a message with a hop-count greater than its MAX_HOP_COUNT. More severe than that, the originator of that message has no control of the scope when different MAX_HOP_COUNTs may appear in the network. A decreasing hop-limit avoids that problem. > - RERR also includes the originator address > This is mostly for extensibility and security purposes. Also, we allow for different error codes in an RERR, again for future extensions in companion documents. > - definition of a FLAGS TLV instead of the ackrequired TLV > The ackrequired TLV did not have a value and would therefore be removed by intermediate routers along a route if they did not require a RREP_ACK. This would make end-to-end security even more difficult than it already is for reactive protocols. Therefore, we proposed to always include the TLV and to give it a value (1 for ackrequired, 0 for not required). That means that while the message content may change in the TLV value, the position of the TLV value and the length of the message do not change, making integrity protection easier. Since we already use the one byte for the 1-bit value, we instead specify a FLAGS TLV with 7 bits than can be used by extensions in companion documents. > - pre-allocation of two metrics in the IANA registries > We defined the hop-count metric, which is only a fallback if an intermediate router does not know the metric-type of an incoming routing message. It will then set the TLV value to the maximum value (filled with all '1's) and change the metric-type to hop-count, then the routers can use the information from the routing message and use the msg-hop-count field instead of the metric value. Another predefined metric is a dimensionless metric (similar to OLSRv2) with a float as value. We thought about using the same encoding for the metric as used in OLSRv2, section 6.2. However, that is used for a single link; we would need 8 more bits (255 hops maximum), which would make alignment difficult. Also, route-metric is included only once in the message, whereas the link metric in OLSRv2 is included per neighbor, therefore saving one or two extra bytes is more important in OLSRv2 than for LOADng. Any other metrics can still be added to the registry at any time. Ulrich > > Best regards > Ulrich > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 7, 2013 at 7:33 PM > Subject: New Version Notification for draft-clausen-lln-loadng-07.txt > To: ulrich@herberg.name > Cc: jiazi@jiaziyi.com, axel@axelcdv.com, t.clausen@computer.org, > charliep@computer.org, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com, > yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, > hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil > > > > A new version of I-D, draft-clausen-lln-loadng-07.txt > has been successfully submitted by Ulrich Herberg and posted to the > IETF repository. > > Filename: draft-clausen-lln-loadng > Revision: 07 > Title: The Lightweight On-demand Ad hoc Distance-vector Routing > Protocol - Next Generation (LOADng) > Creation date: 2013-01-07 > WG ID: Individual Submission > Number of pages: 67 > URL: > http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-07.txt > Status: http://datatracker.ietf.org/doc/draft-clausen-lln-loadng > Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-07 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-07 > > Abstract: > This document describes the Lightweight Ad hoc On-Demand - Next > Generation (LOADng) distance vector routing protocol, a reactive > routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). > > > > > The IETF Secretariat > > > --f46d043c7bd46385ed04d2ca7413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

as it has been requested, I will provide some rationale for the = changes in the latest revision:

On Mon, J= an 7, 2013 at 7:40 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

we have submitted a new revision = of LOADng. Here is a summary of the changes:

- many editorial improv= ements

The document is better to read now, and is better ali= gned with other WG documents / RFCs in MANET.
=A0
- better characterization of applicability of LOADng (describing the constr= aints/traffic flows etc. instead of listing a number of use cases)

The rationale for the change was that rather than claiming= that the protocol is useful for particular use cases, we describe the appl= icability of the protocol for certain network/traffic properties. This is s= imilar to other MANET protocols we have standardized.


=A0
- some parameters that have been router parameters are now interface parame= ters, which allows for using different settings for different interface typ= es

RREQ_MAX_JITTER and USE_BIDIRECTIONAL_LINK_ONLY= are now interface parameters.
MANET routers may have multiple interfaces with different properties (e.g.,= one wireless interface, one Ethernet interface). In such cases, it is adva= ntageous to allow for more flexibility of the parameters per interface.
RREQ_RATELIMIT has been replaced by RREQ_MIN_INTERVAL, which determines the minimum interval betw= een two consecutive RREQs. The purpose is the same, but it is easier to imp= lement and better aligned with other MANET RFCs.

=A0
- RREQ/RREP/RERR include hop-li= mit for scope limitations (mostly for allowing extensions as companion docu= ment, e.g. expanding ring search)

As said, this allows for limiting the scope of messag= es. Before, we only had hop-count, which in theory could also be used to li= mit the scope. However, a problem arises when different routers in the MANE= T have different settings of MAX_HOP_COUNT; a router could receive a messag= e with a hop-count greater than its MAX_HOP_COUNT. More severe than that, t= he originator of that message has no control of the scope when different MA= X_HOP_COUNTs may appear in the network. A decreasing hop-limit avoids that = problem.

=A0
- RERR also includes the originator address

This i= s mostly for extensibility and security purposes. Also, we allow for differ= ent error codes in an RERR, again for future extensions in companion docume= nts.

=A0
- definition of a FLAGS TLV ins= tead of the ackrequired TLV

The ackrequired TLV di= d not have a value and would therefore be removed by intermediate routers a= long a route if they did not require a RREP_ACK. This would make end-to-end= security even more difficult than it already is for reactive protocols. Th= erefore, we proposed to always include the TLV and to give it a value (1 fo= r ackrequired, 0 for not required). That means that while the message conte= nt may change in the TLV value, the position of the TLV value and the lengt= h of the message do not change, making integrity protection easier.
Since we already use the one byte for the 1-bit value, we instead specify a= FLAGS TLV with 7 bits than can be used by extensions in companion document= s.
=A0
- pre-allocation of two metrics in the IANA registries

We defined the hop-count metric, which is only a fallback if an interm= ediate router does not know the metric-type of an incoming routing message.= It will then set the TLV value to the maximum value (filled with all '= 1's) and change the metric-type to hop-count, then the routers can use = the information from the routing message and use the msg-hop-count field in= stead of the metric value.
Another predefined metric is a dimensionless metric (similar to OLSRv2) wit= h a float as value. We thought about using the same encoding for the metric= as used in OLSRv2, section 6.2. However, that is used for a single link; w= e would need 8 more bits (255 hops maximum), which would make alignment dif= ficult. Also, route-metric is included only once in the message, whereas th= e link metric in OLSRv2 is included per neighbor, therefore saving one or t= wo extra bytes is more important in OLSRv2 than for LOADng.
Any other metrics can still be added to the registry at any time.

Ul= rich
=A0

Best regards
Ulrich


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan= 7, 2013 at 7:33 PM
Subject: New Version Notification for draft-clausen-lln-loadng-07.txt
To= : ulrich@herberg.n= ame
Cc: jiazi= @jiaziyi.com, axe= l@axelcdv.com, t.clausen@computer.org, charliep@computer.org, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com, yui= chi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, hiroki.satoh.yj@hitac= hi.com, jde= an@itd.nrl.navy.mil



A new version of I-D, draft-clausen-lln-loadng-07.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-clausen-lln-loadng
Revision: =A0 =A0 =A0 =A007
Title: =A0 =A0 =A0 =A0 =A0 The Lightweight On-demand Ad hoc Distance-vector= Routing Protocol - Next Generation (LOADng)
Creation date: =A0 2013-01-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 67
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/int= ernet-drafts/draft-clausen-lln-loadng-07.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draf= t-clausen-lln-loadng
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-clausen= -lln-loadng-07
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?= url2=3Ddraft-clausen-lln-loadng-07

Abstract:
=A0 =A0This document describes the Lightweight Ad hoc On-Demand - Next
=A0 =A0Generation (LOADng) distance vector routing protocol, a reactive
=A0 =A0routing protocol intended for use in Mobile Ad hoc NETworks (MANETs)= .




The IETF Secretariat



--f46d043c7bd46385ed04d2ca7413-- From ulrich@herberg.name Tue Jan 8 10:00:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF3121F86A6 for ; Tue, 8 Jan 2013 10:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6pMj5RPjMJv for ; Tue, 8 Jan 2013 10:00:12 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED221F8684 for ; Tue, 8 Jan 2013 10:00:10 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so688581vba.27 for ; Tue, 08 Jan 2013 10:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=46sy+MNKNYRyKGhVakWJXbSTA4Jpi9TjbhVKlhp9QN4=; b=BMI1YU87qC93dpK2ZL1jTibRKq2Ov827ZoR1OH/41re+IV79oBPc3bBCWbuvASqiRa rPaHRtcCz7T8wVT7jQgatCBa6gtbRWNmyS749UlPvzOxTlp2kMqubproKCh5EgZsdVDg cwmDqFREprv5PA+Jv1/WB+t0rvMTDPxXTd5nI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=46sy+MNKNYRyKGhVakWJXbSTA4Jpi9TjbhVKlhp9QN4=; b=XDk59/5inEo/DQ0DHiRYTSk4mJc3AB7x10IFPPu2vfnLlpLuWtpGGleH+1ycZRMhP1 qxn4I+AXv493nmHqbI/L00oxU1DeiyN74ATxsHqKd1S3gt1Yk/OV2Xi07ifepU2d4WB9 +djM235t/EHgEU9+Dbe1CsNfha9GhmWxHM+S09ebOZLh+8Wb5q9HflRbpQWBEoS+bKtT FZg8nFFOC+u/vnotrMleragPJwwSG0e5U/zyFXQQGTnbasmg3XIgc53VDq/iIRHqjUJy XEDU3Tha3nnHd9hjx7k2iwx3VzoGknLe6c6aD9VHEPJLmNuFalgKYZcXAuW/d2wTaQUz g1cA== MIME-Version: 1.0 Received: by 10.58.229.197 with SMTP id ss5mr2659792vec.14.1357668009625; Tue, 08 Jan 2013 10:00:09 -0800 (PST) Received: by 10.220.249.72 with HTTP; Tue, 8 Jan 2013 10:00:09 -0800 (PST) In-Reply-To: References: <20130107215052.26500.1897.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 10:00:09 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7bd6c3106fc8b404d2cab7a0 X-Gm-Message-State: ALoCoQmI0Oy59I/COkU+7Z/XUt9iSTCXhW2+Mb2qlrCRRj5OD+dhZg1W0KN/xwiBX1o85ddz1XT+ Subject: Re: [manet] New Version Notification for draft-herberg-lln-loadng-mib-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:00:13 -0000 --047d7bd6c3106fc8b404d2cab7a0 Content-Type: text/plain; charset=ISO-8859-1 P.S. Essentially, this new revision incorporates the changes of the latest LOADng draft to the router/interface parameters Best regards Ulrich On Mon, Jan 7, 2013 at 7:41 PM, Ulrich Herberg wrote: > We have also updated the LOADng-MIB document: > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 7, 2013 at 1:50 PM > Subject: New Version Notification for draft-herberg-lln-loadng-mib-02.txt > To: ulrich@herberg.name > Cc: robert.g.cole@us.army.mil, t.clausen@computer.org > > > > A new version of I-D, draft-herberg-lln-loadng-mib-02.txt > has been successfully submitted by Ulrich Herberg and posted to the > IETF repository. > > Filename: draft-herberg-lln-loadng-mib > Revision: 02 > Title: Definition of Managed Objects for the Lightweight > On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) > Creation date: 2013-01-07 > WG ID: Individual Submission > Number of pages: 43 > URL: > http://www.ietf.org/internet-drafts/draft-herberg-lln-loadng-mib-02.txt > Status: > http://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib > Htmlized: > http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-herberg-lln-loadng-mib-02 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes objects for configuring parameters of the > Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next > Generation (LOADng) process on a router. The MIB module defined in > this memo, denoted LOADng-MIB, also reports state. While LOADng is > layer agnostic and can be run with different address families (e.g., > on L2 using MAC addreses, or on L3 using IP addresss), this MIB > module assumes that LOADng is used on L3, and uses only IPv4/IPv6 > addresses. > > > > > The IETF Secretariat > > > --047d7bd6c3106fc8b404d2cab7a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable P.S. Essentially, this new revision incorporates the changes of the latest = LOADng draft to the router/interface parameters

Best regards
Ulri= ch

On Mon, Jan 7, 2013 at 7:41 PM, Ulrich= Herberg <ulrich@herberg.name> wrote:
We have also updated the LOADng-MIB document= :


---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Mon, Jan 7, 2013 at 1:50 PM
Subject: New Version Notification for = draft-herberg-lln-loadng-mib-02.txt
To: ulrich@herberg.name
Cc: robert.g.cole@us.army.mil, = t.clausen@compu= ter.org



A new version of I-D, draft-herberg-lln-loadng-mib-02.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-herberg-lln-loadng-mib
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Definition of Managed Objects for the Lightweigh= t On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOAD= ng)
Creation date: =A0 2013-01-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 43
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org= /internet-drafts/draft-herberg-lln-loadng-mib-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/= draft-herberg-lln-loadng-mib
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-her= berg-lln-loadng-mib-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcd= iff?url2=3Ddraft-herberg-lln-loadng-mib-02

Abstract:
=A0 =A0This memo defines a portion of the Management Information Base (MIB)=
=A0 =A0for use with network management protocols in the Internet community.=
=A0 =A0In particular, it describes objects for configuring parameters of th= e
=A0 =A0Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next=
=A0 =A0Generation (LOADng) process on a router. =A0The MIB module defined i= n
=A0 =A0this memo, denoted LOADng-MIB, also reports state. =A0While LOADng i= s
=A0 =A0layer agnostic and can be run with different address families (e.g.,=
=A0 =A0on L2 using MAC addreses, or on L3 using IP addresss), this MIB
=A0 =A0module assumes that LOADng is used on L3, and uses only IPv4/IPv6 =A0 =A0addresses.




The IETF Secretariat



--047d7bd6c3106fc8b404d2cab7a0-- From sratliff@cisco.com Tue Jan 8 10:01:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90DE11E80ED for ; Tue, 8 Jan 2013 10:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOPljXyg7Mjt for ; Tue, 8 Jan 2013 10:01:02 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3771911E80DF for ; Tue, 8 Jan 2013 10:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1090; q=dns/txt; s=iport; t=1357668062; x=1358877662; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IjYq333YwCH6RkoFiszA+iNBYj3ZsztMQMIqHcNkaBA=; b=dl5UIAloSJGoSCk7BJi8sGDkwL3ei7dPGer0iR5nyhtVzKj6hkRbL6iY +MXqOzLqSstYChDK4+vhd7DqBArPgfUrPHoj9PTOslk4VlcgKpO3AO5wL uNzSzbigFANNm9K61r+l455r5HHud6rrTf5Jg2aF0qFMY6wjCElyz6QXt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI9d7FCtJV2Z/2dsb2JhbABEvV4Wc4IfAQEEgQkCASokMiUCBBuID6lqjSCMXYNXYQOILJ4pgnSBcTU X-IronPort-AV: E=Sophos;i="4.84,432,1355097600"; d="scan'208";a="160127348" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jan 2013 18:01:02 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r08I11kM029084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Jan 2013 18:01:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 12:01:01 -0600 From: "Stan Ratliff (sratliff)" To: " List" Thread-Topic: MANET Reactive Protocols Thread-Index: AQHN7coeczdNPIf0IkuYSUY+BUuILw== Date: Tue, 8 Jan 2013 18:01:00 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFD30B8@xmb-aln-x03.cisco.com> References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A77231BFB0A@xmb-rcd-x02.cisco.com> <50EC5274.7070809@computer.org> In-Reply-To: <50EC5274.7070809@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] MANET Reactive Protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:01:02 -0000 Hello WG participants,=20 It is a good thing that both of the reactive protocol documents have update= d versions; I would like to thank the authors of both docs for continuing t= o progress the state of the art.=20 That being said, let us endeavor to, for the moment, keep the discussion fo= cused on the technical aspects, shying away from the purely editorial. We h= ave active involvement from the ADs; a path forward will hopefully emerge. = Any discussion about stylistic or purely editorial content of the two docum= ents is, IMHO, "beating a dead horse". Those judgements are inherently subj= ective, therefore, it is easy for people to reach different conclusions. One other item I feel compelled to mention with regard to this debate: I be= lieve strongly that "Honorable people can disagree honorably." I think that= the some of the email threads surrounding the reactive protocols (and no, = I will not be more specific than that) sometime lose sight of that notion. = So I ask you to please remember this, and think before you post.=20 Regards, Stan= From abdussalambaryun@gmail.com Tue Jan 8 10:23:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9488421F8540 for ; Tue, 8 Jan 2013 10:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQK4vYt-h3Qr for ; Tue, 8 Jan 2013 10:23:08 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA1221F8480 for ; Tue, 8 Jan 2013 10:23:08 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so706406vbb.35 for ; Tue, 08 Jan 2013 10:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oLyN+Bjntpnw3QKs23EmYDpfQZCyo5sSt0j6kct0Z8I=; b=EAE5kq35dNC3rNppugNFLBDBYfb7WsNQT8MLFu+na5Cxx81X+FTfh9yISxYLL5Kgcu ndTEbx0qK94m41nfNDQuQ3jMHeRI/K+O5RPvcsMWLCdZxUMGD7WO+k0JuwKNjGtez5WS WWETd0b6A1SV7B1YZzfFrCEn+505PDsq6jehzRgbQ5K6DDL9iLCovlXb4Th4pX4JjU2V HhdvnhhJhnmZmVsuaNMCYp2ycvm1KCgEAcO8o3dhx5OrQZrsyuaPUWyDCvEymIyTD2EW dw7QIh9i2C5KFijUmZwDP+00gA/HvIGNxvHlHVXAA8GsHwxQkpytBu0d5FCnGnsIi/1e 6RfA== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr75373960vdc.125.1357669388036; Tue, 08 Jan 2013 10:23:08 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 8 Jan 2013 10:23:07 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 19:23:07 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:23:09 -0000 Hi Herberg, thanks for reply. My question was as below: >> Is this a MUST for the protocol or a SHOULD? , >> > > I don't understand that question. > Is thoes parameters that are now added to interfaces a MUST for the interface to have for the protocol purposes? Regards AB From ulrich@herberg.name Tue Jan 8 10:35:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3251F0C6A for ; Tue, 8 Jan 2013 10:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtzCQvQH2b4w for ; Tue, 8 Jan 2013 10:35:25 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4573821F8518 for ; Tue, 8 Jan 2013 10:35:23 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so726699vcb.17 for ; Tue, 08 Jan 2013 10:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R7qfopfjVG1P3aXwQi3QoHWTmOMVkrrowHSEUK7OUpA=; b=wtuXIZ40PqsTTjAsMKUrVUYpbxsBvXtGzC8B1DbPrKHn3aPQYSnxTL1yX2Nry4EPKM l5BhbpUvMGjaMKT67rV3RP20NBdnSzY2qkJXmXAvHXEJAtlB5VEPk7JuRVxy23G8JlHh B/M0CFDf7c1jwyJMjYrYF71QzNaCZ2DW0W34s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=R7qfopfjVG1P3aXwQi3QoHWTmOMVkrrowHSEUK7OUpA=; b=gY+gz1TCprVUysgdEmMqf59mhRvMSXm+e8064aAOVKlYQuRy1NIUsJCxmwnA3gcVCr uOs5rjznj+l2TsIq0gUIxXMKp+d/loJF5v0XxRf3YJ7SzQZllEtHeV5PitK82PAK8HmE GxjxePF7qDueY90FlkHI9ml7gD6XDy6D+mF+BjkCq8QPgK5BAw2P7xuFx6VFJ+LBDW2e b4xAJUKaTfiFHhKzQSGAXWKJpTfpt0ZvyiLvJIyVtA5uCvueqwShPrw4vCuP54OyiC4Z MlTeQ5F8pkKgBuPsFTM0vZd3dFNbkLE997iJ5esf1w5kRuxJRvr0HL0zRB1/rOwxx87E KcfA== MIME-Version: 1.0 Received: by 10.58.49.130 with SMTP id u2mr90902662ven.0.1357670123306; Tue, 08 Jan 2013 10:35:23 -0800 (PST) Received: by 10.220.249.72 with HTTP; Tue, 8 Jan 2013 10:35:23 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 10:35:23 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=089e013cbd3e6bfee004d2cb350e X-Gm-Message-State: ALoCoQlxT63WmK4I/APrsqOMMEYUBg0RIi5zRXyE6hehCPKP8bP+DIuOjjRGmq5mEnbzNic+WW0O Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:35:25 -0000 --089e013cbd3e6bfee004d2cb350e Content-Type: text/plain; charset=ISO-8859-1 Abdussalam, I think that listing the parameters does not require the use of RFC2119 language (see RFC2119 section 6). We followed the same way that other MANET RFCs (e.g. RFC6130) use parameters/constants. RFC2119 language is used in the appropriate sections when the parameters are used, e.g., section 12: " Two consequent RREQs generated on an interface of a LOADng Router SHOULD be separated at least RREQ_MIN_INTERVAL." Best regards Ulrich On Tue, Jan 8, 2013 at 10:23 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Herberg, > > thanks for reply. My question was as below: > > >> Is this a MUST for the protocol or a SHOULD? , > >> > > > > I don't understand that question. > > > > Is thoes parameters that are now added to interfaces a MUST for the > interface to have for the protocol purposes? > > Regards > AB > --089e013cbd3e6bfee004d2cb350e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Abdussalam,

I think that listing the parameters does not require the= use of RFC2119 language (see RFC2119 section 6). We followed the same way = that other MANET RFCs (e.g. RFC6130) use parameters/constants. RFC2119 lang= uage is used in the appropriate sections when the parameters are used, e.g.= , section 12: " Two consequent RREQs generated on an interface of a LOADng Router SHOULD be separated at least RREQ_MIN_INTERVAL."=

Best regards
Ulrich

On Tue, Ja= n 8, 2013 at 10:23 AM, Abdussalam Baryun <abdussalambaryun@gmail.= com> wrote:
Hi Herberg,

thanks for reply. My question was as below:

>> Is this a MUST for the protocol or a SHOULD? ,
>>
>
> I don't understand that question.
>

Is thoes parameters that are now added to interfaces a MUST for the interface to have for the protocol purposes?

Regards
AB

--089e013cbd3e6bfee004d2cb350e-- From abdussalambaryun@gmail.com Tue Jan 8 10:43:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A305911E80D9 for ; Tue, 8 Jan 2013 10:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjrT4xm+YV4y for ; Tue, 8 Jan 2013 10:43:28 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id DC6FB11E80A2 for ; Tue, 8 Jan 2013 10:43:27 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so729636vba.41 for ; Tue, 08 Jan 2013 10:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ng/ij1OTKHe/xBpmYkXJyLoAVMuTWJvueekvsOuHw5k=; b=rCaqBcIpq8rWGOhiwOF2IgJQEI0BgV4NUfIF8gN/YfwY9BXjTd4hC4836ez2K3W35W Z98mSBEWtKB/39as8ZVJPJ+senWjX4H/WA7o7YWWrRB5wowu1Yo110t1K8u5W7vL8mbP xWFtBzjEQ3qpThOTHImk/PnGxPvFN5BJUuTwQRLOr+qT8fOPwLpO/cdzbFaIKrp7PzDc YWZBuczouAKGmig60SbL5yulQIdSIp1l8H34TkZo23GqtXlmGhdGtRK8chzMMXXGdg0K F/h9WacPrBHGpDHEsEt5BmrOnRa7YyMn3287xPEY20qRLjCvUwLfAcb/iMVxT/ecdZIo sEwg== MIME-Version: 1.0 Received: by 10.220.149.69 with SMTP id s5mr87821864vcv.23.1357670607259; Tue, 08 Jan 2013 10:43:27 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 8 Jan 2013 10:43:27 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFD30B8@xmb-aln-x03.cisco.com> References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A77231BFB0A@xmb-rcd-x02.cisco.com> <50EC5274.7070809@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFD30B8@xmb-aln-x03.cisco.com> Date: Tue, 8 Jan 2013 19:43:27 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] MANET Reactive Protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:43:28 -0000 Hi Stan, Thanks for reminder. I agree with you, but not only reactive proto., I had confusions with the proactive protocol as well, few participants don't reply friendly/clearly as I understood, there was confusion with DLEP once we got no much replies to some enquiries (but now solved). However, I will try my best to follow your advise. Therefore, as a participant I will need that the WG chair or co-chair remind us from time to time to reply/comment/input to make this WG progress. As from my reading experience of other WGs that WG chair's frequent input on the list makes the WG participants more able to make new input/decisions. Thanks for your input, AB On 1/8/13, Stan Ratliff (sratliff) wrote: > Hello WG participants, > > It is a good thing that both of the reactive protocol documents have updated > versions; I would like to thank the authors of both docs for continuing to > progress the state of the art. > > That being said, let us endeavor to, for the moment, keep the discussion > focused on the technical aspects, shying away from the purely editorial. We > have active involvement from the ADs; a path forward will hopefully emerge. > Any discussion about stylistic or purely editorial content of the two > documents is, IMHO, "beating a dead horse". Those judgements are inherently > subjective, therefore, it is easy for people to reach different > conclusions. > > One other item I feel compelled to mention with regard to this debate: I > believe strongly that "Honorable people can disagree honorably." I think > that the some of the email threads surrounding the reactive protocols (and > no, I will not be more specific than that) sometime lose sight of that > notion. So I ask you to please remember this, and think before you post. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Jan 8 12:46:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340F211E80D1 for ; Tue, 8 Jan 2013 12:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qw7PUJuwqQV for ; Tue, 8 Jan 2013 12:46:28 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5011E80A2 for ; Tue, 8 Jan 2013 12:46:28 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id p16so851953vcq.25 for ; Tue, 08 Jan 2013 12:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=frAAfxBNaPPKKgZ+ap+h3Y8DSKn2RPiaY1DG4aqqFBg=; b=u6W4q7FlEl/BiQWzJRVA9szfsxQtxfdNMXv2YJWdjrv+l/JM+8zwf9N2IgxVQ7/Msx eon5Daz/9yYxJ1j9gzpw4QUPwy8AvmfoHmiS2SmTgoZPh6UPPCavxvzuKpFyofb4YtU7 lmi7uO127j8vBWmLe6m5HkDN/o0oJV3T9KeaHeqYTsym8bnr0DkO3KrAmoTqCAxa/d0n gClXUa3tVxV2JQl9OiGd9siaqJzOC+RaKjN6GzdriVlUymo1zn/Qa7/BnhzF+0BPpBJG 2G8WGR0SmbnWKheKoXtBc0nWmwV8uy2dskCC4X1e0aqE4m93/jYC8V8xOKpuq+iaxc31 J3yg== MIME-Version: 1.0 Received: by 10.52.21.179 with SMTP id w19mr77155706vde.55.1357677987807; Tue, 08 Jan 2013 12:46:27 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 8 Jan 2013 12:46:27 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 21:46:27 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 20:46:29 -0000 Hi Herberg, I try to separate not the use of 2119 but the functions of LOADng and its interfaces. I don't mean the 2119 use but its affects. So I was thinking that if an interface of LOADng failed to have thoes parameters will the protocol LOADng still perform. I think your answer is yes. AB On 1/8/13, Ulrich Herberg wrote: > Abdussalam, > > I think that listing the parameters does not require the use of RFC2119 > language (see RFC2119 section 6). We followed the same way that other MANET > RFCs (e.g. RFC6130) use parameters/constants. RFC2119 language is used in > the appropriate sections when the parameters are used, e.g., section 12: " > Two consequent RREQs generated on an interface of a LOADng Router SHOULD be > separated at least RREQ_MIN_INTERVAL." > > Best regards > Ulrich > > On Tue, Jan 8, 2013 at 10:23 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Herberg, >> >> thanks for reply. My question was as below: >> >> >> Is this a MUST for the protocol or a SHOULD? , >> >> >> > >> > I don't understand that question. >> > >> >> Is thoes parameters that are now added to interfaces a MUST for the >> interface to have for the protocol purposes? >> >> Regards >> AB >> > From ulrich@herberg.name Tue Jan 8 13:21:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A336211E80A2 for ; Tue, 8 Jan 2013 13:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSdQnL7yh-Mt for ; Tue, 8 Jan 2013 13:21:45 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id A5A761F0CFA for ; Tue, 8 Jan 2013 13:21:44 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id n11so916536vch.30 for ; Tue, 08 Jan 2013 13:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ecrX9/iaI8Kj/TBP6BqxeA5V2VTJjkLciXIkgysdD18=; b=dU1XOf3MOLA7/L4DiNeJIEx/WvetjeUzrsabEKTBz/Hd5OuhHUbRCT8Lr7RYjIgp5e udEu6kGYdDZxsxHVr5FdED7qsz3tbOyb969p7yHohubn7PzjXx5xB+MYfjqVE9DSMnAf DozpmzRl/fWK2+PXU2Olfro/xAgWwmYSxCtQA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ecrX9/iaI8Kj/TBP6BqxeA5V2VTJjkLciXIkgysdD18=; b=C+a/aWrWCQGtPeQl3c2NVBxCN6N88QEBidTPmwhUImjOzDZok40IY5rjIr3HI+JM3I iqUPqKPE1LCO00FRe4OJOXjZ7QUP9yovZpiqcYcEzWrZyClio+5BI3Zzu8g3Bv2eNHT1 HAJCGqrzk280ISb/j9nTcXNvZRYsIRPkhTwxzhepHlctmCipVbyHpCTg6Gee6nn2yTNo j3GVewo/46T/Aeyp1+NoS1FEOyXCsE4+KzVi6seHGkJYroEGT8VDBwqq+1z5mP7CZ5sM yB5dJM4HRthXk2Z/WnoZSzqKcLF90MCZFN76lAdfuuNg4igUXUgbQxirVeGzEO6OG0qc ySXw== MIME-Version: 1.0 Received: by 10.52.66.51 with SMTP id c19mr52732811vdt.123.1357680104015; Tue, 08 Jan 2013 13:21:44 -0800 (PST) Received: by 10.220.249.72 with HTTP; Tue, 8 Jan 2013 13:21:43 -0800 (PST) In-Reply-To: References: <20130108033334.15919.2147.idtracker@ietfa.amsl.com> Date: Tue, 8 Jan 2013 13:21:43 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf3071ce3e5187fa04d2cd885e X-Gm-Message-State: ALoCoQm4lKEtfBEfSv8r+6XQlW6P7SXObD8kJk9BIJ7qjnmyLPr+Gs8aDV1oJxa97jCJK+nY+CNB Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 21:21:49 -0000 --20cf3071ce3e5187fa04d2cd885e Content-Type: text/plain; charset=ISO-8859-1 Hi Abdussalam, On Tue, Jan 8, 2013 at 12:46 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Herberg, > > I try to separate not the use of 2119 but the functions of LOADng and > its interfaces. I don't mean the 2119 use but its affects. So I was > thinking that if an interface of LOADng failed to have thoes > parameters will the protocol LOADng still perform. I think your answer > is yes. > An implementer may choose to not use such parameters, to rename them, or to implement the internal processing as he/she wants to. However, all the normative part that affect interoperability must follow the RFC2119 notation. So in the example I mentioned, ("Two consequent RREQs generated on an interface of a LOADng Router SHOULD be separated at least RREQ_MIN_INTERVAL."), it is irrelevant how the parameter RREQ_MIN_INTERVAL is implemented, as long as no two consecutive RREQ are generated within less than RREQ_MIN_INTERVAL. Best regards Ulrich > > AB > > On 1/8/13, Ulrich Herberg wrote: > > Abdussalam, > > > > I think that listing the parameters does not require the use of RFC2119 > > language (see RFC2119 section 6). We followed the same way that other > MANET > > RFCs (e.g. RFC6130) use parameters/constants. RFC2119 language is used in > > the appropriate sections when the parameters are used, e.g., section 12: > " > > Two consequent RREQs generated on an interface of a LOADng Router SHOULD > be > > separated at least RREQ_MIN_INTERVAL." > > > > Best regards > > Ulrich > > > > On Tue, Jan 8, 2013 at 10:23 AM, Abdussalam Baryun < > > abdussalambaryun@gmail.com> wrote: > > > >> Hi Herberg, > >> > >> thanks for reply. My question was as below: > >> > >> >> Is this a MUST for the protocol or a SHOULD? , > >> >> > >> > > >> > I don't understand that question. > >> > > >> > >> Is thoes parameters that are now added to interfaces a MUST for the > >> interface to have for the protocol purposes? > >> > >> Regards > >> AB > >> > > > --20cf3071ce3e5187fa04d2cd885e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Abdussalam,

On Tue, Jan 8, 2013 at 12:= 46 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Herberg,=A0

I try to separate not the use of 2119 but the functions of LOADng and
its interfaces. I don't mean the 2119 use but its affects. So I was
thinking that if an interface of LOADng failed to have thoes
parameters will the protocol LOADng still perform. I think your answer
is yes.

An implementer may choose to not use such = parameters, to rename them, or to implement the internal processing as he/s= he wants to. However, all the normative part that affect interoperability m= ust follow the RFC2119 notation. So in the example I mentioned, ("Two = consequent RREQs generated on an interface of a LOADng Router SHOULD be sep= arated at least RREQ_MIN_INTERVAL."), it is irrelevant how the paramet= er RREQ_MIN_INTERVAL is implemented, as long as no two consecutive RREQ are= generated within less than RREQ_MIN_INTERVAL.

Best regards
Ulrich

=A0

AB

On 1/8/13, Ulrich Herberg <ulrich= @herberg.name> wrote:
> Abdussalam,
>
> I think that listing the parameters does not require the use of RFC211= 9
> language (see RFC2119 section 6). We followed the same way that other = MANET
> RFCs (e.g. RFC6130) use parameters/constants. RFC2119 language is used= in
> the appropriate sections when the parameters are used, e.g., section 1= 2: "
> Two consequent RREQs generated on an interface of a LOADng Router SHOU= LD be
> separated at least RREQ_MIN_INTERVAL."
>
> Best regards
> Ulrich
>
> On Tue, Jan 8, 2013 at 10:23 AM, Abdussalam Baryun <
> abdussalambaryun@gmail.c= om> wrote:
>
>> Hi Herberg,
>>
>> thanks for reply. My question was as below:
>>
>> >> Is this a MUST for the protocol or a SHOULD? ,
>> >>
>> >
>> > I don't understand that question.
>> >
>>
>> Is thoes parameters that are now added to interfaces a MUST for th= e
>> interface to have for the protocol purposes?
>>
>> Regards
>> AB
>>
>

--20cf3071ce3e5187fa04d2cd885e-- From abdussalambaryun@gmail.com Wed Jan 9 04:02:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C4321F859A for ; Wed, 9 Jan 2013 04:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11joNLVGR9d8 for ; Wed, 9 Jan 2013 04:02:17 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 021C821F8598 for ; Wed, 9 Jan 2013 04:02:16 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id ez10so1449291vbb.11 for ; Wed, 09 Jan 2013 04:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UtBPwBBB+vvlW7g3xgxVrOOQhdXxBtChYG9PdDtkiRI=; b=Eyp7F3Vty+Ulh/RhmkLtZ/zBs9BKOFz3MasvEz8rk30b13lPBmh36R83sRtMKQlySv mK9t/4DTR/5HCfGQzxgS2X2ZBdSIwOZb7NNaM7L+Q9VFHR5Lg3UntXaJQAkc6OrGI3U1 Xe+JSQTuEbr0KK2SlC5uCHyX6Rmn24VvE6sy2FTxfGXMZc2ikEFhwK6ObqBH0fqMxR00 4GgkD6WEVaJm0ivudCY6nQ//S09P8GdJFXDAIkoImQX1YbekBQExAIo41Ei9OgqcEAxL Bt1R+Nuk1r5tcfZ+DlpMH9FytUuXToRZifUCcc+S7UsscuRo93ppEn+HHwDxsMvDGWMr AD7Q== MIME-Version: 1.0 Received: by 10.58.31.200 with SMTP id c8mr8398779vei.23.1357732936494; Wed, 09 Jan 2013 04:02:16 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 9 Jan 2013 04:02:16 -0800 (PST) Date: Wed, 9 Jan 2013 13:02:16 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] comments for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 12:02:17 -0000 To: Authors of the work LOADng, I start review the doc, got to page 9 so far it is interesting, 4> Generate control traffic based on network events only: when a new route is required, or when an active route is detected broken. Specifically, this protocol does not require periodic signaling. Not sure what is *event* why not needed signaling. I may understand the meaning, but I think the event is not defined, so it seems general. Recommend to define it, 12.4> RREQs, whether initially generated or forwarded, are sent to all neighbor LOADng Routers through all interfaces in the Local Interface Set. I think it not should send to ALL intf but only intrf with similar metric type, please reply for discussion, Regards AB +++++++++++++++++++++++++ Note: If this message not replied by any author within a month, it will be sent to the AD to get a response from the authors. +++++++++++++++++++++++++ From yi.jiazi@gmail.com Wed Jan 9 04:53:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA86D21F85AC for ; Wed, 9 Jan 2013 04:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrCDsNYnR95y for ; Wed, 9 Jan 2013 04:53:03 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4B21F858E for ; Wed, 9 Jan 2013 04:53:02 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id ji2so893413bkc.1 for ; Wed, 09 Jan 2013 04:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=3tPe2UjAhxSY1ss1m8mSDIa80RGUpOApj9J7T6qCYmo=; b=sKP380IcDXm/dir+HDz4XR5b0uVegppxj6cHklUFPHtdA0unO+u3rGMIEOTu1udkWc AaDayNw0OSfH7f30Sqyw98mjnCDGVylvypREcmA/C0lH1v/BaqN9hlBwmaI9Y1X6lSjF NHggaEP83jAQJrXSUBaHlAMTNtuDA+CQUrnfnmoG2oZAm6FATeSRs5LOMJwko0NzMoee ixGqpB8TXDzSNVmsdQ+LeSNK5fChkc0RXBAmRfpNtmmdpQcV64X1iW2EwtGUz9kx8I3Y Fng7LaABeh68pdJRe+rZwJqMzstfVRdpPc51I/7pnhV1Xx8HgWaxw5uPDupjAuJv9ANp objw== X-Received: by 10.204.6.21 with SMTP id 21mr34429859bkx.77.1357735981786; Wed, 09 Jan 2013 04:53:01 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id o7sm48563967bkv.13.2013.01.09.04.53.00 (version=SSLv3 cipher=OTHER); Wed, 09 Jan 2013 04:53:01 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Wed, 9 Jan 2013 13:52:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7130D090-7193-4734-A32D-45908B116644@jiaziyi.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] comments for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 12:53:03 -0000 Hi AB,=20 please check inline: On Jan 9, 2013, at 1:02 PM, Abdussalam Baryun = wrote: > To: Authors of the work LOADng, >=20 > I start review the doc, got to page 9 so far it is interesting, >=20 > 4> Generate control traffic based on network events only: when a new > route is required, or when an active route is detected broken. > Specifically, this protocol does not require periodic signaling. >=20 > Not sure what is *event* why not needed signaling. I may understand > the meaning, but I think the event is not defined, so it seems > general. Recommend to define it, The "events" are defined clearly: when a new route is required, or when an active route is detected broken. It's *periodic* signaling that is not required, i.e. like HELLO and TC = messages used on OLSR.=20 >=20 > 12.4> RREQs, whether initially generated or forwarded, are sent to all > neighbor LOADng Routers through all interfaces in the Local = Interface > Set. >=20 > I think it not should send to ALL intf but only intrf with similar > metric type, please reply for discussion, LOADng supports different metric types in the network. In fact, for = LOADng, it can run in a heterogeneous environments with different = interfaces (i.e. possible different metric types are sued). So it's = important that different metric types are supported. Limiting the = RREQ/RREP transmission to the metric types, might result in = disconnections in the network.=20 LOADng provides a "fallback" to HOP_COUNT metric if an interface gets a = message with the metric type that it doesn't understand.=20 best Jiazi >=20 > Regards > AB > +++++++++++++++++++++++++ > Note: If this message not replied by any author within a month, > it will be sent to the AD to get a response from the authors. > +++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From trac+manet@trac.tools.ietf.org Wed Jan 9 12:25:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90421F87E7 for ; Wed, 9 Jan 2013 12:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooTwzbLR1fmd for ; Wed, 9 Jan 2013 12:25:11 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 081EF21F8698 for ; Wed, 9 Jan 2013 12:25:04 -0800 (PST) Received: from localhost ([127.0.0.1]:49049 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tt2Cs-0008AN-9C; Wed, 09 Jan 2013 21:25:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 09 Jan 2013 20:25:02 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/9 Message-ID: <061.a0055255c275fede343be9cc794f90e9@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #9: Reserved value for AODVv2 SeqNum -- is it necessary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:25:13 -0000 #9: Reserved value for AODVv2 SeqNum -- is it necessary From Henning Rogge on October 22: >> The value zero (0) is reserved to indicate that the !SeqNum >> for a destination address is unknown. > I think its a REALLY bad habit to define some crazy rules for sequence > numbers. All generated DYMO message will have sequence numbers, so if > a node remembers another node and its addresses, it also remembers the > sequence number. Whether or not to specify a reserved !SeqNum is not a trivial issue. With recent revisions, it is now feasible to conduct a Route Discovery cycle (RREQ / RREP) without need for indicating that a !SeqNum is invalid, and there do not seem to be any other instances in the current specification where a !SeqNum has to be reported as invalid. If there is to be a reserved value for !SeqNum, it seems that 0 (zero) is a good choice, so that rollover skips from 65535 to 1 bypassing the reserved value of zero. -- ----------------------------------+---------------------------------------- Reporter: | Owner: Charlie Perkins charliep@computer.org | Status: new Type: defect | Milestone: Priority: minor | Version: Component: dymo | Keywords: Sequence number management Severity: Active WG Document | ----------------------------------+---------------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Wed Jan 9 12:54:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B0421F88E4 for ; Wed, 9 Jan 2013 12:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npRH5uEe-Uyt for ; Wed, 9 Jan 2013 12:54:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5717F21F88CB for ; Wed, 9 Jan 2013 12:54:53 -0800 (PST) Received: from localhost ([127.0.0.1]:50659 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tt2fk-0000U2-29; Wed, 09 Jan 2013 21:54:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 09 Jan 2013 20:54:52 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/10 Message-ID: <061.df2fe01bc52131cb4e0926c8ff7c0ff4@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #10: Reporting multiple broken routes whose metric types are different X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:54:54 -0000 #10: Reporting multiple broken routes whose metric types are different Currently, RERR messages carry a single !AddrBlk. The Metric Type of the addresses in the !AddrBlk is specified in the !MetricType Message TLV, so all addresses in the RERR !AddrBlk have the same address type. If the route table has routes from the same network interface with unequal Metric Types, then a broken link from that interface could well require reporting broken routes with unequal Metric Types. There are at least two solutions to this problem. i) Multiple RERR messages. This is the more expensive solution if measured by cost of using the network media. ii) New Metric Type AddrTLV, and allow multiple !AddrBlks in the RERR. Since a goal of reactive protocols is to minimize network congestion, and solution (ii) seems quite straightforward, it is proposed to be included as an enhancement of RERR functionality. -- -----------------------------------+------------------------------------- Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: RERR, alternate metrics -----------------------------------+------------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Wed Jan 9 13:39:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E9821F8505 for ; Wed, 9 Jan 2013 13:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0uLjPDmC3JE for ; Wed, 9 Jan 2013 13:39:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C73F11F0C6A for ; Wed, 9 Jan 2013 13:39:50 -0800 (PST) Received: from localhost ([127.0.0.1]:53336 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tt3NB-0002u3-9S; Wed, 09 Jan 2013 22:39:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 09 Jan 2013 21:39:45 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/11 Message-ID: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #11: Error: failure of delivery to single host can invalidate route to an entire network X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 21:39:51 -0000 #11: Error: failure of delivery to single host can invalidate route to an entire network In section 8.4, an !UnreachableNode.Address for a single host could match a subnet route in the intermediate node's route table, and current specification leads to invalidating the entire subnet route. This is an error. The intermediate router should keep the route to the subnet, but create a host route to the specific host, and flag that specific route as Broken. A similar error can occur when an !UnreachableNode.Address is reported with a !PrefixLength indicating unreachability for a subnet. If the intermediate route table has a route entry with a shorter !PrefixLength than reported in the RERR, then the intermediate router should not invalidate the larger subnet. Instead, it should only invalidate the part of the larger subnet which is indicated by the !PrefixLength given in the RERR !AddrBlk. In this way, future packets destined to nodes unaffected by the broken route (but on the same larger subnet) can be delivered without requiring additional Route Discovery flooding. -- -----------------------------------+-------------------------------- Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: RERR, subnet route -----------------------------------+-------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Wed Jan 9 13:56:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB4C21F8863 for ; Wed, 9 Jan 2013 13:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZWDODRE15kB for ; Wed, 9 Jan 2013 13:56:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BCEEB21F8862 for ; Wed, 9 Jan 2013 13:56:19 -0800 (PST) Received: from localhost ([127.0.0.1]:54564 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tt3dC-0002EF-FW; Wed, 09 Jan 2013 22:56:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 09 Jan 2013 21:56:18 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/12 Message-ID: <061.c0c6fb135fcc7bb4ca27b05c03dc55ba@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #12: INVALID_PREFIX_LENGTH -- is it useful? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 21:56:20 -0000 #12: INVALID_PREFIX_LENGTH -- is it useful? In AODVv2, all routes have known prefix lengths, which can be the same as the length of the IP address family of the route's destination (in which case, they are known as "host routes"). Only when there is no route, is it possible for a destination to have an unknown prefix length. In that case, the RERR message has only a single destination address in its !AddrBlk, and since the !PrefixLength is unknown, it is simply not included. Since there are not any cases where INVALID_PREFIX_LENGTH has to be assigned, it should be deleted from the specification. For all destinations that do not have explicitly known subnet prefixes, the !PrefixLength must be reported to be the length of IP addresses for the relevant address family (i.e., 4 for IPv4 or 16 for IPv6). -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: new Priority: trivial | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: INVALID_PREFIX_LENGTH -----------------------------------+----------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Wed Jan 9 14:26:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3B21F844C for ; Wed, 9 Jan 2013 14:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1oX2re902lN for ; Wed, 9 Jan 2013 14:26:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 294B921F845F for ; Wed, 9 Jan 2013 14:26:49 -0800 (PST) Received: from localhost ([127.0.0.1]:56661 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tt46h-0002af-Vl; Wed, 09 Jan 2013 23:26:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 09 Jan 2013 22:26:47 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/13 Message-ID: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:26:51 -0000 #13: Supporting monotonically nondecreasing but non-additive metrics There are some useful metrics that are nondecreasing but not "naturally" additive. That is, making an additive definition for them requires unnatural mental gymnastics. A good example is "1 / bandwidth". This metric is not affected by higher-bandwidth links, but only by the link that has the least bandwidth from among all the path components of the route. Strangely, this quantity does not seem to have a commonly accepted name that I can find. The best I can do so far is to call it the "Slowness" metric. One could use the Slowness metric as a nondecreasing metric which still finds the fastest route. Supporting such metrics in AODVv2 can be done by simply replacing "!RteMsg.Metric + Cost(L)" by another function that could be called "!TotalCost (!RteMsg.Metric, Cost(L))". The impact on the specification is minor (only a few lines), and the possible future benefit could be substantial. For !HopCount, !TotalCost(!RteMsg.Metric,Cost(L)) is defined to be (!RteMsg.Metric + 1). -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: nondecreasing metrics -----------------------------------+----------------------------------- Ticket URL: manet From charliep@computer.org Wed Jan 9 14:45:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CC021F8505 for ; Wed, 9 Jan 2013 14:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW0Hxz9WLC3K for ; Wed, 9 Jan 2013 14:45:07 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id D075E21F84B6 for ; Wed, 9 Jan 2013 14:44:59 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tt4OI-0002IT-Rl for manet@ietf.org; Wed, 09 Jan 2013 17:44:58 -0500 Message-ID: <50EDF2E7.3020105@computer.org> Date: Wed, 09 Jan 2013 14:44:55 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861afd69a2a17f01d0f3485a46150722f1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:45:08 -0000 Hello folks, I've added several issues to the Issue Tracker. I look forward to discussion on the issues. You can simply reply to the list, and I can add the substantive points from email to the issue tracker. Or you can go to the IETF tools page: http://trac.tools.ietf.org/wg/manet/trac/query?status=new&status=assigned&status=reopened&component=dymo The Trac wiki syntax requires putting in '!' escapes preceding the mixed-case variable names. This unfortunately appears also in Trac's emails to the WG list, and deTracs from readability. I'll try to figure out how to report this bug to the IETF tools team, to see if they have any interest in fixing it. -- Regards, Charlie P. From marius@itee.uq.edu.au Wed Jan 9 23:26:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C677B21F8849 for ; Wed, 9 Jan 2013 23:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onpbiyLRmwCy for ; Wed, 9 Jan 2013 23:26:30 -0800 (PST) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id C450E21F882E for ; Wed, 9 Jan 2013 23:26:29 -0800 (PST) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id r0A7QIVY012766; Thu, 10 Jan 2013 17:26:18 +1000 Received: from UQEXET2.soe.uq.edu.au (uqexet2.soe.uq.edu.au [130.102.129.39]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id r0A7QHVA002869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Jan 2013 17:26:17 +1000 Received: from uqexht4.soe.uq.edu.au (130.102.129.73) by UQEXET2.soe.uq.edu.au (130.102.129.39) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jan 2013 17:26:17 +1000 Received: from UQEXMDA1.soe.uq.edu.au ([169.254.1.125]) by uqexht4.soe.uq.edu.au ([130.102.129.73]) with mapi id 14.01.0355.002; Thu, 10 Jan 2013 17:26:17 +1000 From: Marius Portmann To: "'Charles E. Perkins'" Thread-Topic: Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions Thread-Index: AQHN5t6rY6VHXcvmiUCewJnEoYZjx5hCN8+w Date: Thu, 10 Jan 2013 07:26:16 +0000 Message-ID: <55276FFE1B06A541A659C0B360E8066F191DFF@UQEXMDA1.soe.uq.edu.au> References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au> <50BE4036.30507@computer.org> <50BFA190.7050908@computer.org> <55276FFE1B06A541A659C0B360E8066F181C42@UQEXMDA8.soe.uq.edu.au> <50E0C2D5.6030404@computer.org> In-Reply-To: <50E0C2D5.6030404@computer.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.102.64.21] Content-Type: multipart/alternative; boundary="_000_55276FFE1B06A541A659C0B360E8066F191DFFUQEXMDA1soeuqedua_" MIME-Version: 1.0 X-UQ-FilterTime: 1357802779 X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub Cc: "'manet@ietf.org'" Subject: Re: [manet] Duplicate suppression for RREQ and RREP -- Problem and Proposed Solutions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:26:32 -0000 --_000_55276FFE1B06A541A659C0B360E8066F191DFFUQEXMDA1soeuqedua_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Charlie, Thanks for your reply. The latest draft of the AODVv2 appears to solve the= problem of loss of RREQ and RREP messages we raised. With this solution in place, there appears to be no further need to increme= nt a node's sequence number when it issues a route reply (unless needed to = match the sequences number requested in the received RREQ message). In fact= , we think that the policy of ALWAYS incrementing a node's sequence number = when it initiates a route reply can lead to non-optimal routes. We will pos= t the details in a separate email. cheers Marius, Rob, Peter, Wee Lum From: Charles E. Perkins [mailto:charliep@computer.org] Sent: Monday, 31 December 2012 8:40 AM To: Marius Portmann Cc: 'manet@ietf.org' Subject: Duplicate suppression for RREQ and RREP -- Problem and Proposed So= lutions Hello folks, As noted by Marius Portmann et al., there are some subtleties about using sequence numbers to inhibit dissemination of possibly outdated RREQ and RREP messages. After reconsidering this matter for the last couple of weeks, I realized that the existing specification does not properly handle suppression of duplicate multicast messages. In order to accomplish that, while still not suppressing earlier multicast messages that do need to be transmitted, a list of previously retransmitted multicast AODVv2 routing messages needs to be maintained, as suggested by Marius. Here is some proposed text for that purpose: Two incoming RREQ messages should be considered the "same" if they have the same Sequence Number and were generated by the same AODVv2 router. Using that notion of equivalence, when RREQ messages are multicast in a MANET, a node may well receive the same RREQ from more than one of its neighbors. Such duplicated RREQs SHOULD NOT be retransmitted; otherwise, a great deal of unnecessary signaling traffic is likely to be generated in the network as multicast RREQs are retransmitted over and over again with practically no additional benefit. To avoid unnecessary retransmission of duplicate RREQ messages, while still enabling the proper handling of earlier RREQ messages that may have somehow been delayed in the network, it is needed for each AODVv2 router to keep a list of the RREQ messages which it has recently retransmitted. The same duplicate suppression is needed for other AODVv2 messages. For instance, when optional multicast RREP is used to enable selection from among multiple possible return routes, similar measures need to be taken. For this reason, the table is more generally called the AODVv2 Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ and RREP messages which have been recently multicast, using the above notion of message equivalence. More formally, two AODVv2 RREQ messages are equivalent if: - they were generated by the same AODVv2 router (RREQ_gen) - RREQ_Gen assigned the same Sequence Number to its routing information in the RREQs - the RREQs are for the same desired destination address An analogous definition applies for a RREP message, in case that the RREP message would be multicast. Protocol handling of RERR messages eliminates the need for tracking RERR messages, since the rules for retransmitting RERR multicast messages prevent the phenomenon of message duplication (that can affect RREQ and RREP retransmission). As a historical note, AODV and early versions of DYMO contained a similar broadcast suppression mechanism. Prior to initiating the conversion to RFC 5444 compliance, Ian and I had thought that the underlying multicast optimization would do a better job of duplicate suppression, and in a manner already integrated with the underlying forwarding mechanisms. Thanks, Marius et al. for triggering a re-examination of this issue which has needed attention since the RFC 5444 compliance changes. On 12/13/2012 6:09 PM, Marius Portmann wrote: Hi Charlie, .................... >> (2) Route Reply Loss >> -------------------- >> AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/= current/msg05702.html). >> The reason is that route replies are only forwarded by an >> intermediate node when the node updates its routing table. ................ > The relevant point is that an AODVv2 router retransmits the RREQ or > RREP regardless of whether the AODVv2 router used the incoming > routing information to update its route table. > > I thought there might be some wording to the contrary, but after > reading the relevant parts of the specification several times I > haven't found any such wording. Please let me know what I have missed. Our analysis was based on DYMO/AODVv2 version 23. It now appears that in ve= rsion 24, the specification has changed such that it is similar to what we = are proposing, i.e. to let the AODVv2 routers always forward the RREQ/RREP = messages. All the best, Rob, Peter, Marius and Wee Lum -- Regards, Charlie P. --_000_55276FFE1B06A541A659C0B360E8066F191DFFUQEXMDA1soeuqedua_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Charlie,

 

Thanks for your reply.  The latest d= raft of the AODVv2 appears to solve the problem of loss of RREQ and RREP me= ssages we raised.

 

With this solution in place, there appear= s to be no further need to increment a node's sequence number when it issue= s a route reply (unless needed to match the sequences number requested in the received RREQ message). In fact, we thin= k that the policy of ALWAYS incrementing a node's sequence number when it i= nitiates a route reply can lead to non-optimal routes. We will post the det= ails in a separate email.

 

cheers

Marius, Rob, Peter, Wee Lum

=  

=  

= From: Charles E. Perkins [mailto:charliep@computer.org]
Sent: Monday, 31 December 20= 12 8:40 AM
To: Marius Portmann
Cc: 'manet@ietf.org'
Subject: Duplicate suppressi= on for RREQ and RREP -- Problem and Proposed Solutions

 

Hello folks,

As noted by Marius Portmann et al., there are some subtleties about
using sequence numbers to inhibit dissemination of possibly
outdated RREQ and RREP messages.  After reconsidering this
matter for the last couple of weeks, I realized that the existing
specification does not properly handle suppression of duplicate
multicast messages.  In order to accomplish that, while still
not suppressing earlier multicast messages that do need to be
transmitted, a list of previously retransmitted multicast AODVv2
routing messages needs to be maintained, as suggested by Marius.

Here is some proposed text for that purpose:

Two incoming RREQ messages should be considered the "same" if
they have the same Sequence Number and were generated by the same
AODVv2 router.  Using that notion of equivalence, when RREQ messages are multicast in a MANET, a node may well receive the same RREQ from
more than one of its neighbors.  Such duplicated RREQs SHOULD NOT
be retransmitted; otherwise, a great deal of unnecessary signaling
traffic is likely to be generated in the network as multicast RREQs
are retransmitted over and over again with practically no additional
benefit.

To avoid unnecessary retransmission of duplicate RREQ messages,
while still enabling the proper handling of earlier RREQ messages
that may have somehow been delayed in the network, it is needed
for each AODVv2 router to keep a list of the RREQ messages which
it has recently retransmitted.

The same duplicate suppression is needed for other AODVv2 messages.
For instance, when optional multicast RREP is used to enable selection
from among multiple possible return routes, similar measures need to
be taken.

For this reason, the table is more generally called the AODVv2
Duplicate Suppression Table; it is simply a list of the AODVv2 RREQ
and RREP messages which have been recently multicast, using
the above notion of message equivalence.  More formally, two
AODVv2 RREQ messages are equivalent if:
- they were generated by the same AODVv2 router (RREQ_gen)
- RREQ_Gen assigned the same Sequence Number to its
  routing information in the RREQs
- the RREQs are for the same desired destination address
An analogous definition applies for a RREP message, in case that
the RREP message would be multicast.

Protocol handling of RERR messages eliminates the need for
tracking RERR messages, since the rules for retransmitting RERR
multicast messages prevent the phenomenon of message duplication
(that can affect RREQ and RREP retransmission).

As a historical note, AODV and early versions of DYMO contained
a similar broadcast suppression mechanism.  Prior to initiating the conversion to RFC 5444 compliance, Ian and I had thought that the
underlying multicast optimization <via SMF> would do a better
job of duplicate suppression, and in a manner already integrated
with the underlying forwarding mechanisms.  Thanks, Marius et al.
for triggering a re-examination of this issue which has needed
attention since the RFC 5444 compliance changes.

On 12/13/2012 6:09 PM, Marius Portmann wrote:

= Hi Charlie,

 

.................= ...

>> (2) Route Reply Loss<= /span>

>> --------------------<= /span>

>> AODV can lose route replies (h= ttp://www.ietf.org/mail-archive/web/manet/current/msg05702.html).

>> The reason is that route replies= are only forwarded by an

>> intermediate node when the node = updates its routing table.

 

................



> The relevant point is that an AODVv2= router retransmits the RREQ or

> RREP regardless of whether the AODVv= 2 router used the incoming

> routing information to update its ro= ute table.

>

> I thought there might be some wordin= g to the contrary, but after

> reading the relevant parts of the sp= ecification several times I

> haven't found any such wording. = ; Please let me know what I have missed.

 

Our analysis was based on DYMO/AODVv2 ver= sion 23. It now appears that in version 24, the specification has changed s= uch that it is similar to what we are proposing, i.e. to let the AODVv2 routers always forward the RREQ/RREP messages.=

 

All the best,

Rob, Peter, Marius and Wee Lum=

=  



-- 
Regards,
Charlie P.
--_000_55276FFE1B06A541A659C0B360E8066F191DFFUQEXMDA1soeuqedua_-- From Peter.Hoefner@nicta.com.au Wed Jan 9 23:26:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7E521F8917 for ; Wed, 9 Jan 2013 23:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+eLx3b6GHf2 for ; Wed, 9 Jan 2013 23:26:50 -0800 (PST) Received: from ajax.nicta.com.au (ajax.nicta.com.au [221.199.217.11]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8C21F8910 for ; Wed, 9 Jan 2013 23:26:50 -0800 (PST) Received: from atp-exchmbx1.it.nicta.com.au ([221.199.216.119] helo=atp-exchmbx1.in.nicta.com.au) by ajax.nicta.com.au with esmtp (Exim 4.72) (envelope-from ) id 1TtCXF-00072k-53; Thu, 10 Jan 2013 18:26:49 +1100 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx1.in.nicta.com.au (221.199.216.119) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 18:26:42 +1100 Received: from callisto.dynhost.nicta.com.au (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 18:26:41 +1100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1283) From: =?iso-8859-1?Q?Peter_H=F6fner?= Date: Thu, 10 Jan 2013 18:26:41 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> To: X-Mailer: Apple Mail (2.1283) X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19544.003 X-TM-AS-Result: No--16.478200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-SA-Exim-Connect-IP: 221.199.216.119 X-SA-Exim-Mail-From: Peter.Hoefner@nicta.com.au X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on ajax.nicta.com.au) Cc: Wee Lum Tan , Rob van Glabbeek Subject: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:30:30 -0000 While analysing AODVv2 we came across a potential problem: we can show that (at least in combination with intermediate route reply) always incrementing sequence numbers when issuing a route reply can lead to non-optimal routes. A detailed example is given at http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf The example does not use any unusual set-up (special topology, special time of link breaks, etc); hence we think that this type of behaviour can happen frequently. However, we have not done any measurements. Moreover, a similar example can occur without intermediate route reply (when only the destination is allowed to answer); but that scenario needs a dynamic topology or a message-loss during transmission. A solution could be to only increment sequence numbers when needed. More precisely, the sequence number of the destination node (generating the= reply) would be set as the maximum of the current sequence number of that node and= the incremented (by 1) sequence number from the received RREQ message. Is there a problem with not incrementing sequence numbers all the time? Cheers Peter, Rob, Marius, Wee Lum P.S. This mail may be relevant for ticket #6 in the MANET Trac system ________________________________ The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments. From henning.rogge@fkie.fraunhofer.de Wed Jan 9 23:35:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5C21F8904 for ; Wed, 9 Jan 2013 23:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47VUbhUZqpAW for ; Wed, 9 Jan 2013 23:35:14 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE921F884A for ; Wed, 9 Jan 2013 23:35:13 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TtCfQ-0001kv-9u for manet@ietf.org; Thu, 10 Jan 2013 08:35:12 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TtCfQ-0007GK-7F for manet@ietf.org; Thu, 10 Jan 2013 08:35:12 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 10 Jan 2013 08:35:11 +0100 Message-ID: <50EE6F28.6040300@fkie.fraunhofer.de> Date: Thu, 10 Jan 2013 08:35:04 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50EDF2E7.3020105@computer.org> In-Reply-To: <50EDF2E7.3020105@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050804010201020205040000" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16456/Thu Jan 10 01:34:51 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8ac2e9db9cb74b112e4303f89b85ed9a Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:35:15 -0000 --------------ms050804010201020205040000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/09/2013 11:44 PM, Charles E. Perkins wrote: > > Hello folks, > > I've added several issues to the Issue Tracker. I look forward to > discussion > on the issues. You can simply reply to the list, and I can add the > substantive > points from email to the issue tracker. Or you can go to the IETF tool= s > page: > http://trac.tools.ietf.org/wg/manet/trac/query?status=3Dnew&status=3Das= signed&status=3Dreopened&component=3Ddymo > > > The Trac wiki syntax requires putting in '!' escapes preceding the > mixed-case variable names. This unfortunately appears also in Trac's > emails > to the WG list, and deTracs from readability. I'll try to figure out h= ow > to report this bug to the IETF tools team, to see if they have any inte= rest > in fixing it. I would also like to put an issue on the tracker that AODV2 use the=20 position and structure of the RFC5444 addresses as protocol information=20 at the moment, I feel this might become a major headache in the future. Both AODVv1 and OLSRv1 used binary network messages where the position=20 in the message provided information about the data itself. With RFC5444 OLSRv2 stepped away from this, using the TLVs to mark the=20 type of information within the message stream. This makes the message=20 much easier to extend. AODVv2 is a BAD step backward compared to OLSRv2 because it mixes the=20 TLV-based format of RFC5444 with implicit demands on the internal=20 structure and order of the address blocks and its addresses. If AODVv2 uses a message for information type X, it should mark this=20 with a TLV. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050804010201020205040000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTAwNzM1MDlaMCMGCSqGSIb3DQEJBDEWBBQlA7zFqryhke4G3TkwEB9hcyxoljBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAEUbstaSkVsSrDOT8KUlXjxC71jFZ6qxMu9emkLmZMX73 KrRPIWYvCVljsoO0p+js3FQg0k37p3cBoIzUu3TdhASiTrlDDLRCGv9i2GSnIrgY5aKrW1v/ VnoB3LmYsCIemVrjVYQEmDExqnehjC9+tXUSNEIeEqaFrVZaU9ZUKmG1xiJ7Yj1mrJCixCXK MSeNCzUJA+PFh94l+XAHyf3+QaTCVPLBW+2Zf74Af9U5Jd0Gol+5TY+cJ3JOEynwPULcmDVr 9uQPceVPYt/IvTJ+SGWzgoCmOC3hbC6a1p0y4gXXSjELy2ySVKk1Tys7dC5DIJ1JG7lWWvfc rA+j5w4o/AAAAAAAAA== --------------ms050804010201020205040000-- From henning.rogge@fkie.fraunhofer.de Wed Jan 9 23:36:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396B821F841F for ; Wed, 9 Jan 2013 23:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji4mgkWw4-bC for ; Wed, 9 Jan 2013 23:36:55 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDCB21F84C9 for ; Wed, 9 Jan 2013 23:36:55 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TtCh2-0003E5-Vr for manet@ietf.org; Thu, 10 Jan 2013 08:36:53 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TtCh2-0007HA-TB for manet@ietf.org; Thu, 10 Jan 2013 08:36:52 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 10 Jan 2013 08:36:52 +0100 Message-ID: <50EE6F93.3070302@fkie.fraunhofer.de> Date: Thu, 10 Jan 2013 08:36:51 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> In-Reply-To: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020806060001060703090500" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16456/Thu Jan 10 01:34:51 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: dad17b0fa7a976ea34f8545b3e71195d Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:36:56 -0000 --------------ms020806060001060703090500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/10/2013 08:26 AM, Peter H=F6fner wrote: > While analysing AODVv2 we came across a potential problem: > we can show that (at least in combination with intermediate route reply= ) > always incrementing sequence numbers when issuing a route reply can > lead to non-optimal routes. > > A detailed example is given at > http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf > > The example does not use any unusual set-up (special topology, special > time of link breaks, etc); hence we think that this type of behaviour > can happen frequently. However, we have not done any measurements. > > Moreover, a similar example can occur without intermediate route > reply (when only the destination is allowed to answer); but that > scenario needs a dynamic topology or a message-loss during transmission= =2E > > A solution could be to only increment sequence numbers when needed. > More precisely, the sequence number of the destination node (generating= the reply) > would be set as the maximum of the current sequence number of that node= and the > incremented (by 1) sequence number from the received RREQ message. > > Is there a problem with not incrementing sequence numbers all the time?= Just as a thought, maybe AODVv2 needs something like the ANSN in OLSRv2=20 to have sequence numbers for message duplicate suppression and the ANSN=20 to differentiate between different sets of data? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020806060001060703090500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTAwNzM2NTFaMCMGCSqGSIb3DQEJBDEWBBS770gersEisebzankj7cGrNT/USjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAHkcxDmrxC3b7zw4RNEr1cee1+HUTraqkRrOdXYR5rQ8W uCiZXDpwbl+vCX0WGDysKu/jUVzBvbQS0GfIEdZQtYgL4MSIxZjT0yD52YHpA/MZbF1nSboS yzfnyigjKf8/XYG8/vMLw07kGJp+rBMcoMUTlh4r2FAB7yKU6xfK/nAYrhJKX63E2QgdpI6o xloS/PQSSxOBx3AUeO4nnvjzbcKCUY36UqrLNGcD41F7UruIEXutLdmLfWr6Rmxll0lMYGYe i5hm8qKmVHLf2MGVVyL5hSxsKtAkjJNUAqDSrG7h5E1Ji+Xuuz/vCMPRTutUckXENAOfvk89 VYEXlYmU+gAAAAAAAA== --------------ms020806060001060703090500-- From charliep@computer.org Wed Jan 9 23:42:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14E921F8923 for ; Wed, 9 Jan 2013 23:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYSImJFfuky7 for ; Wed, 9 Jan 2013 23:42:46 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8254321F8911 for ; Wed, 9 Jan 2013 23:42:46 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TtCmj-0003cf-7L; Thu, 10 Jan 2013 02:42:45 -0500 Message-ID: <50EE70F0.2020604@computer.org> Date: Wed, 09 Jan 2013 23:42:40 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> In-Reply-To: <50EE6F28.6040300@fkie.fraunhofer.de> Content-Type: multipart/alternative; boundary="------------040808060305080209040006" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86eb8c1577999f84d8a20115ed97f85caa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:42:48 -0000 This is a multi-part message in MIME format. --------------040808060305080209040006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Henning, I'll put the issue on the Issue Tracker tomorrow. However, there have been many protocols using positional information for lists (of addresses, etc) without impairment of extensibility. This is especially true when extensions go at the end. Do you have any particular example in mind where RFC 5444 somehow creates a problem with this? Regards, Charlie P. On 1/9/2013 11:35 PM, Henning Rogge wrote: > On 01/09/2013 11:44 PM, Charles E. Perkins wrote: >> >> Hello folks, >> >> I've added several issues to the Issue Tracker. I look forward to >> discussion >> on the issues. You can simply reply to the list, and I can add the >> substantive >> points from email to the issue tracker. Or you can go to the IETF tools >> page: >> http://trac.tools.ietf.org/wg/manet/trac/query?status=new&status=assigned&status=reopened&component=dymo >> >> >> >> The Trac wiki syntax requires putting in '!' escapes preceding the >> mixed-case variable names. This unfortunately appears also in Trac's >> emails >> to the WG list, and deTracs from readability. I'll try to figure out >> how >> to report this bug to the IETF tools team, to see if they have any >> interest >> in fixing it. > > I would also like to put an issue on the tracker that AODV2 use the > position and structure of the RFC5444 addresses as protocol > information at the moment, I feel this might become a major headache > in the future. > > Both AODVv1 and OLSRv1 used binary network messages where the position > in the message provided information about the data itself. > > With RFC5444 OLSRv2 stepped away from this, using the TLVs to mark the > type of information within the message stream. This makes the message > much easier to extend. > > AODVv2 is a BAD step backward compared to OLSRv2 because it mixes the > TLV-based format of RFC5444 with implicit demands on the internal > structure and order of the address blocks and its addresses. > > If AODVv2 uses a message for information type X, it should mark this > with a TLV. > > Henning Rogge > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------040808060305080209040006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Henning,

I'll put the issue on the Issue Tracker tomorrow.

However, there have been many protocols using positional information
for lists (of addresses, etc) without impairment of extensibility.
This is especially true when extensions go at the end.  Do you have
any particular example in mind where RFC 5444 somehow creates
a problem with this?

Regards,
Charlie P.



On 1/9/2013 11:35 PM, Henning Rogge wrote:
On 01/09/2013 11:44 PM, Charles E. Perkins wrote:

Hello folks,

I've added several issues to the Issue Tracker.  I look forward to
discussion
on the issues.  You can simply reply to the list, and I can add the
substantive
points from email to the issue tracker.  Or you can go to the IETF tools
page:
http://trac.tools.ietf.org/wg/manet/trac/query?status=new&status=assigned&status=reopened&component=dymo


The Trac wiki syntax requires putting in '!' escapes preceding the
mixed-case variable names.  This unfortunately appears also in Trac's
emails
to the WG list, and deTracs from readability.  I'll try to figure out how
to report this bug to the IETF tools team, to see if they have any interest
in fixing it.

I would also like to put an issue on the tracker that AODV2 use the position and structure of the RFC5444 addresses as protocol information at the moment, I feel this might become a major headache in the future.

Both AODVv1 and OLSRv1 used binary network messages where the position in the message provided information about the data itself.

With RFC5444 OLSRv2 stepped away from this, using the TLVs to mark the type of information within the message stream. This makes the message much easier to extend.

AODVv2 is a BAD step backward compared to OLSRv2 because it mixes the TLV-based format of RFC5444 with implicit demands on the internal structure and order of the address blocks and its addresses.

If AODVv2 uses a message for information type X, it should mark this with a TLV.

Henning Rogge 


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------040808060305080209040006-- From abdussalambaryun@gmail.com Wed Jan 9 23:59:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930C121F88EF for ; Wed, 9 Jan 2013 23:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CaN3GV0xliC for ; Wed, 9 Jan 2013 23:59:28 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7A95621F8472 for ; Wed, 9 Jan 2013 23:59:28 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so225309vby.19 for ; Wed, 09 Jan 2013 23:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SBNg40I9YdnSzNwFGEiD3LXsAZ32Kw3e0APpq70tvsA=; b=Zcfm/ncAKEQzZDNjvRiEpfwcnX5832trPgpFH8UsYBeofNMgQJVDmb3/rYhDAJzUWa oKFIbY6oZKukheEYaR1sTZFHAXZgNYBg7Jyp8jQTj1Fj32oI9ziHAa67rhq2fgIixN+G CgB9QFOefqLr+Vvp8dKK/wTYiL2FgGRqlN6eoK1OJBTUGTiOJ82rzvQfeD55FJk5gCw9 lf9E7N85/oZyJbq22SsthNCaYZy1qPi1bs2l+iLOuSJSvLX+dTb1/CinvbyHu3ZE5Fsf w1cYG26rUW2VC4qEFcYTlMszbEZ5P53oI3TnP2BRo646Deo2IR3rPfdFbOLSK14LYJtv LIAw== MIME-Version: 1.0 Received: by 10.220.247.136 with SMTP id mc8mr12018713vcb.44.1357804767439; Wed, 09 Jan 2013 23:59:27 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 9 Jan 2013 23:59:27 -0800 (PST) In-Reply-To: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> Date: Thu, 10 Jan 2013 08:59:27 +0100 Message-ID: From: Abdussalam Baryun To: =?ISO-8859-1?Q?Peter_H=F6fner?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:59:29 -0000 j node informs the the d node of such route otherwise how does the d node know the route to the source s. we don't forget that the cost of both routes are not equal, AB On 1/10/13, Peter H=F6fner wrote: > While analysing AODVv2 we came across a potential problem: > we can show that (at least in combination with intermediate route reply) > always incrementing sequence numbers when issuing a route reply can > lead to non-optimal routes. > > A detailed example is given at > http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf > > The example does not use any unusual set-up (special topology, special > time of link breaks, etc); hence we think that this type of behaviour > can happen frequently. However, we have not done any measurements. > > Moreover, a similar example can occur without intermediate route > reply (when only the destination is allowed to answer); but that > scenario needs a dynamic topology or a message-loss during transmission. > > A solution could be to only increment sequence numbers when needed. > More precisely, the sequence number of the destination node (generating t= he > reply) > would be set as the maximum of the current sequence number of that node a= nd > the > incremented (by 1) sequence number from the received RREQ message. > > Is there a problem with not incrementing sequence numbers all the time? > > Cheers > Peter, Rob, Marius, Wee Lum > > P.S. This mail may be relevant for ticket #6 in the MANET Trac system > > ________________________________ > > The information in this e-mail may be confidential and subject to legal > professional privilege and/or copyright. National ICT Australia Limited > accepts no liability for any damage caused by this email or its > attachments. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Jan 10 00:54:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F001621F890E for ; Thu, 10 Jan 2013 00:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENWSYjOFelnb for ; Thu, 10 Jan 2013 00:54:55 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2576D21F8911 for ; Thu, 10 Jan 2013 00:54:54 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id n11so269910vch.2 for ; Thu, 10 Jan 2013 00:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=geplKd/KM3j3GcbX7jsCMWTqDW+ECWzBU2bSTIU05nI=; b=XsOJ0O9TOuSXrgO1+rBhJAxi3BPCPfXviMBDeW81EvaeLk1IZfX+FbBrz3/nBcVRh3 EPDFhD2WOOnqKV9rF3ilVP98nY9mnx8OHPsFATVtFg0OS3SullJBXmCTY+imV4pRR7dR m8vD30uIm3lsG0Lb+5Ev7PAvjh8ZiEsIluZEFbcUoJP8CSf69XmhO6dV3S7wIu274zen 8a0OxixCLBcffSBujyxefWxvwQfUHrZ+RzSEDHn/TXYFYbBhl0KTh+mwhCDxJuUNFguE 4/8C/qoP+svl4Xqx1nD79iQqJWsCXLED/1zVAUgD41lIq3/piRNDF7/kLhbC5oy+oYnY kTPw== MIME-Version: 1.0 Received: by 10.58.252.72 with SMTP id zq8mr93631200vec.20.1357808094283; Thu, 10 Jan 2013 00:54:54 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 00:54:54 -0800 (PST) In-Reply-To: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> References: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> Date: Thu, 10 Jan 2013 09:54:54 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] #11: Error: failure of delivery to single host can invalidate route to an entire network X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 08:54:56 -0000 I solved that in an implemented AODV another way; the intermediate node (i) should be noticed that a next hop router is lost by receiving RERR, the RERR mentions what is lost. So if the host destination is lost only the source or last (i) in the route should be interested not any (i), others should ignore. AB On 1/9/13, manet issue tracker wrote: > #11: Error: failure of delivery to single host can invalidate route to an > entire > network > > In section 8.4, an !UnreachableNode.Address for a single host could match > a subnet route in the intermediate node's route table, and current > specification leads to invalidating the entire subnet route. This is an > error. The intermediate router should keep the route to the subnet, but > create a host route to the specific host, and flag that specific route > as Broken. > > A similar error can occur when an !UnreachableNode.Address is reported > with a !PrefixLength indicating unreachability for a subnet. If the > intermediate route table has a route entry with a shorter !PrefixLength > than reported in the RERR, then the intermediate router should not > invalidate the larger subnet. Instead, it should only invalidate the > part of the larger subnet which is indicated by the !PrefixLength > given in the RERR !AddrBlk. > > In this way, future packets destined to nodes unaffected by the > broken route (but on the same larger subnet) can be delivered without > requiring additional Route Discovery flooding. > > -- > -----------------------------------+-------------------------------- > Reporter: charliep@computer.org | Owner: Charlie Perkins > Type: defect | Status: new > Priority: major | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: RERR, subnet route > -----------------------------------+-------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Jan 10 01:09:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A2A21F8844 for ; Thu, 10 Jan 2013 01:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMUJSWRqjsXO for ; Thu, 10 Jan 2013 01:09:31 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id E26DA21F882E for ; Thu, 10 Jan 2013 01:09:30 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id p1so272903vcq.24 for ; Thu, 10 Jan 2013 01:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/g9ZrqbRZngb4x57kTdEmC3p/baGD/mZ9ZQ+yTTZSUE=; b=IcaCZfzHUEBiW38mtecM4Mc7Q5ewKSpouVUAXx3R+KEI5e0MiuEJ7PAd7jOivM760f +DN8h5lHbaILVnjzKSftD/EGB2uBSGcgWeNHKdXzsJmNwWylBdWBK4OuIJjFJjlU7LbS M8IGUL70lJNYO8AFW+USzuFQRD5R2qugOUc7v+n6jB2gyVEnxnzhmsRK63IAF3ix6N3Z XPaIM2VNb/lEnRXzydsgN0Gih1s+aYFY5OqC5y+OymEncix4wIDcDGpWUn11TUtb11A6 U8UKcMgrGCpYJN0X1y7gm7i0x8sF79K6DsZ9PheKIxFdpF+PRMj9QfpXtabnx7dJV1iv 6ryw== MIME-Version: 1.0 Received: by 10.220.8.18 with SMTP id f18mr88282280vcf.14.1357808970063; Thu, 10 Jan 2013 01:09:30 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 01:09:30 -0800 (PST) In-Reply-To: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> Date: Thu, 10 Jan 2013 10:09:30 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 09:09:32 -0000 I agree, that is important advantage of using metric and cost for AODVv2. AB On 1/9/13, manet issue tracker wrote: > #13: Supporting monotonically nondecreasing but non-additive metrics > > There are some useful metrics that are nondecreasing but not "naturally" > additive. That is, making an additive definition for them requires > unnatural mental gymnastics. > > A good example is "1 / bandwidth". This metric is not affected by > higher-bandwidth links, but only by the link that has the least bandwidth > from among all the path components of the route. Strangely, this > quantity does not seem to have a commonly accepted name that I can find. > The best I can do so far is to call it the "Slowness" metric. One > could use the Slowness metric as a nondecreasing metric which still > finds the fastest route. > > Supporting such metrics in AODVv2 can be done by simply > replacing "!RteMsg.Metric + Cost(L)" by another function that > could be called "!TotalCost (!RteMsg.Metric, Cost(L))". The impact > on the specification is minor (only a few lines), and the possible > future benefit could be substantial. For !HopCount, > !TotalCost(!RteMsg.Metric,Cost(L)) is defined to be (!RteMsg.Metric + 1). > > -- > -----------------------------------+----------------------------------- > Reporter: charliep@computer.org | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: nondecreasing metrics > -----------------------------------+----------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From Chris.Dearlove@baesystems.com Thu Jan 10 01:50:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA87D21F863A for ; Thu, 10 Jan 2013 01:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwmrqh8G+bi2 for ; Thu, 10 Jan 2013 01:50:05 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9F66F21F8528 for ; Thu, 10 Jan 2013 01:50:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,443,1355097600"; d="scan'208";a="299348408" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Jan 2013 09:50:03 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0A9o2Jt001685 for ; Thu, 10 Jan 2013 09:50:02 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6950"; a="3154018" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 10 Jan 2013 09:50:02 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 10 Jan 2013 09:50:02 +0000 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" , "charliep@computer.org" Thread-Topic: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics Thread-Index: AQHN7rhvpuLsV+vupU6xh2SXwwgn5ZhCT68A Date: Thu, 10 Jan 2013 09:50:01 +0000 Message-ID: References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> In-Reply-To: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 09:50:07 -0000 Such a metric can, in general, lead to looping. Consider A, B, C, D, E in a= ring with metric 2 on links A - B, B - C and C - D, and metric 1 on links = D - E and E - A. Consider a packet from B routed to E. At B it is indiffere= nt whether to go via A or C, so may pick C. At C it is indifferent whether = to go via B or D, so may pick B. Of course in that case one can add the additional rule to not send back on = link just arrived. But a more complicated case can send it in a longer loop= . You could tie-break by number of hops, but that's actually a more complic= ated metric. However something like that is essential - consider a network = all of whose links have metric 1. Whether that tie-breaker is, in general, = sufficient is something not immediately obvious to me. And of course that's in general. A specific routing protocol may ensure tha= t this doesn't happen. But that would also need work to prove. (The essential problem is that non-decreasing is not as good as increasing.= ) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of m= anet issue tracker Sent: 09 January 2013 22:27 To: charliep@computer.org Cc: manet@ietf.org Subject: [manet] #13: Supporting monotonically nondecreasing but non-additi= ve metrics ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- #13: Supporting monotonically nondecreasing but non-additive metrics There are some useful metrics that are nondecreasing but not "naturally" additive. That is, making an additive definition for them requires unnatural mental gymnastics. A good example is "1 / bandwidth". This metric is not affected by higher-bandwidth links, but only by the link that has the least bandwidth from among all the path components of the route. Strangely, this quantity does not seem to have a commonly accepted name that I can find. The best I can do so far is to call it the "Slowness" metric. One could use the Slowness metric as a nondecreasing metric which still finds the fastest route. Supporting such metrics in AODVv2 can be done by simply replacing "!RteMsg.Metric + Cost(L)" by another function that could be called "!TotalCost (!RteMsg.Metric, Cost(L))". The impact on the specification is minor (only a few lines), and the possible future benefit could be substantial. For !HopCount, !TotalCost(!RteMsg.Metric,Cost(L)) is defined to be (!RteMsg.Metric + 1). --=20 -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: nondecreasing metrics -----------------------------------+----------------------------------- Ticket URL: manet _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** From abdussalambaryun@gmail.com Thu Jan 10 02:30:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E921F863C for ; Thu, 10 Jan 2013 02:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vaRhnHnes8w for ; Thu, 10 Jan 2013 02:30:39 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id AFB6821F863A for ; Thu, 10 Jan 2013 02:30:38 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so328263vbb.35 for ; Thu, 10 Jan 2013 02:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D7Y+zpyIuNq+4UrBj1xrtr5EImov52GL8c7CUq/UKjo=; b=pGpciaL+a/pF6CjaBLL3NkfY5O6VKCJw5OvY5qU1Tgi7T9xM+N1KeHriVq4qBqmKLz TFZewsDSPgUUBLxuf/0QGIIKqZhcIUrfSIkJYoCtXSEmKUrgQT7Xw7lr3+Byw8fcWmlW MnCt6igoEZLMzkJO+2MxrsE2zr7oxX7oK+aO3NYRXAUUw9vUFyTk6hNDWm/krR9SoGjj JPQTmRWcoqGFVaRpi98kweW6DIykLylYYRckqwN8KV7X8HxG4wghzthp1DJDElZz+ayv d4Vv6Fdj9RhXt/Ng8QLdmfe/b85TpH5U5R+Z0YyKEzkXfqNmPpKKQ47PI5Pl/WX5t0ap OKWQ== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr77884734vdc.125.1357813837706; Thu, 10 Jan 2013 02:30:37 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 02:30:37 -0800 (PST) In-Reply-To: References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> Date: Thu, 10 Jan 2013 11:30:37 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 10:30:40 -0000 I don't think there is a route until they recieve RREP, the RREP is sent through one route. That packet you mentioned will go through the path of RREP. I don't think in AODVv2 the metric type and function allow loops. comment in line; > Such a metric can, in general, lead to looping. Consider A, B, C, D, E in a > ring with metric 2 on links A - B, B - C and C - D, and metric 1 on links D > - E and E - A. Consider a packet from B routed to E. At B it is indifferent > whether to go via A or C, so may pick C. At C it is indifferent whether to > go via B or D, so may pick B. > At B the data packet will go through only one route which should be the one received RREP from. It will never receive a RREP from both neighbors A and C. At C it will never receive RREP from both nieghbors B and D. > Of course in that case one can add the additional rule to not send back on > link just arrived. AODV does not care about *links*, it care about *vectors*, I think they are different routings even if they may look into the same metric-type but different point of views. > (The essential problem is that non-decreasing is not as good as > increasing.) Is there a prove of that? I am not sure we can fix that, because it will always depend on why the engineer/applicant used that metric in the first place, if that engineer feels that point is true he/she should not use non-decreasing, but for some cases an engineer may like to use such metric so he/she can use it for a reason. AB On 1/10/13, Dearlove, Christopher (UK) wrote: > Such a metric can, in general, lead to looping. Consider A, B, C, D, E in a > ring with metric 2 on links A - B, B - C and C - D, and metric 1 on links D > - E and E - A. Consider a packet from B routed to E. At B it is indifferent > whether to go via A or C, so may pick C. At C it is indifferent whether to > go via B or D, so may pick B. > > Of course in that case one can add the additional rule to not send back on > link just arrived. But a more complicated case can send it in a longer loop. > You could tie-break by number of hops, but that's actually a more > complicated metric. However something like that is essential - consider a > network all of whose links have metric 1. Whether that tie-breaker is, in > general, sufficient is something not immediately obvious to me. > > And of course that's in general. A specific routing protocol may ensure that > this doesn't happen. But that would also need work to prove. > > (The essential problem is that non-decreasing is not as good as > increasing.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > manet issue tracker > Sent: 09 January 2013 22:27 > To: charliep@computer.org > Cc: manet@ietf.org > Subject: [manet] #13: Supporting monotonically nondecreasing but > non-additive metrics > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > #13: Supporting monotonically nondecreasing but non-additive metrics > > There are some useful metrics that are nondecreasing but not "naturally" > additive. That is, making an additive definition for them requires > unnatural mental gymnastics. > > A good example is "1 / bandwidth". This metric is not affected by > higher-bandwidth links, but only by the link that has the least bandwidth > from among all the path components of the route. Strangely, this > quantity does not seem to have a commonly accepted name that I can find. > The best I can do so far is to call it the "Slowness" metric. One > could use the Slowness metric as a nondecreasing metric which still > finds the fastest route. > > Supporting such metrics in AODVv2 can be done by simply > replacing "!RteMsg.Metric + Cost(L)" by another function that > could be called "!TotalCost (!RteMsg.Metric, Cost(L))". The impact > on the specification is minor (only a few lines), and the possible > future benefit could be substantial. For !HopCount, > !TotalCost(!RteMsg.Metric,Cost(L)) is defined to be (!RteMsg.Metric + 1). > > -- > -----------------------------------+----------------------------------- > Reporter: charliep@computer.org | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: nondecreasing metrics > -----------------------------------+----------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/manet > From philippe.jacquet@inria.fr Thu Jan 10 05:44:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0DB21F8678 for ; Thu, 10 Jan 2013 05:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-yu2f63H2yo for ; Thu, 10 Jan 2013 05:44:35 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id D98CA21F8645 for ; Thu, 10 Jan 2013 05:44:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,444,1355094000"; d="scan'208";a="189286077" Received: from zmbs5.inria.fr ([128.93.142.18]) by mail1-relais-roc.national.inria.fr with ESMTP; 10 Jan 2013 14:44:32 +0100 Date: Thu, 10 Jan 2013 14:44:32 +0100 (CET) From: Philippe Jacquet To: "Christopher Dearlove (UK)" Message-ID: <732217576.23387031.1357825472793.JavaMail.root@inria.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.194.164.55] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - FF3.0 (Win)/7.2.0_GA_2669) Cc: manet@ietf.org Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 13:44:37 -0000 I agree with Chris, this may lead to loops if done careless. This metric is the min metric: you replace the + by the min operator, the c= ost of a route is the min bandwidth of the links on the route. The aim is t= o find the route with the max bandwidth, done via an adapted Dijkstra (also= usable with OLSRv2).=20 The problem with this metric is that it does not give an upperbound on the = number of hops (indeed optimal routes may have unlimited hop count via loop= s), and in general it is better to use it with a lexicographical metric (ba= ndwidth,hop-count) so that the optimal route will be the route with the min= hop count among the routes with the largest bandwidth. Everything is computable via Dijkstra since (shortest path on links above b= andwidth threshold).=20 Philippe ----- Mail original ----- De: "Christopher Dearlove (UK)" =C0: manet@ietf.org, charliep@computer.org Envoy=E9: Jeudi 10 Janvier 2013 10:50:01 Objet: Re: [manet] #13: Supporting monotonically nondecreasing but non-addi= tive metrics Such a metric can, in general, lead to looping. Consider A, B, C, D, E in a= ring with metric 2 on links A - B, B - C and C - D, and metric 1 on links = D - E and E - A. Consider a packet from B routed to E. At B it is indiffere= nt whether to go via A or C, so may pick C. At C it is indifferent whether = to go via B or D, so may pick B. Of course in that case one can add the additional rule to not send back on = link just arrived. But a more complicated case can send it in a longer loop= . You could tie-break by number of hops, but that's actually a more complic= ated metric. However something like that is essential - consider a network = all of whose links have metric 1. Whether that tie-breaker is, in general, = sufficient is something not immediately obvious to me. And of course that's in general. A specific routing protocol may ensure tha= t this doesn't happen. But that would also need work to prove. (The essential problem is that non-decreasing is not as good as increasing.= ) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of m= anet issue tracker Sent: 09 January 2013 22:27 To: charliep@computer.org Cc: manet@ietf.org Subject: [manet] #13: Supporting monotonically nondecreasing but non-additi= ve metrics ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- #13: Supporting monotonically nondecreasing but non-additive metrics There are some useful metrics that are nondecreasing but not "naturally" additive. That is, making an additive definition for them requires unnatural mental gymnastics. A good example is "1 / bandwidth". This metric is not affected by higher-bandwidth links, but only by the link that has the least bandwidth from among all the path components of the route. Strangely, this quantity does not seem to have a commonly accepted name that I can find. The best I can do so far is to call it the "Slowness" metric. One could use the Slowness metric as a nondecreasing metric which still finds the fastest route. Supporting such metrics in AODVv2 can be done by simply replacing "!RteMsg.Metric + Cost(L)" by another function that could be called "!TotalCost (!RteMsg.Metric, Cost(L))". The impact on the specification is minor (only a few lines), and the possible future benefit could be substantial. For !HopCount, !TotalCost(!RteMsg.Metric,Cost(L)) is defined to be (!RteMsg.Metric + 1). --=20 -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: nondecreasing metrics -----------------------------------+----------------------------------- Ticket URL: manet _______________________________________________ manet mailing list manet@ietf.org https://www.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://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Jan 10 08:58:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4F21F88DA for ; Thu, 10 Jan 2013 08:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeBeueYV4BCn for ; Thu, 10 Jan 2013 08:58:47 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8770D21F8923 for ; Thu, 10 Jan 2013 08:58:47 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id n11so561734vch.30 for ; Thu, 10 Jan 2013 08:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o3sjxvohAg8RTfvIZZJKV8OvxI5lzZRAmOp9F4zl0z0=; b=UOpYFB3u+6BfjNNTHF9YTbiHlrwjUwaDP/kLGazJBjupltJkD8ZWBVzCpGtUv4a6GU +agjyJs0wBokAM6C7TT+F/qTgrUFzLeCw6wcWMbV7XMlxJppvt5Dt9U5JoapOnTiakuO JlNMteQsp4PVsewIoOaTYS55/3IDx2FKyKRhw15+yp/CHk6zeZ6dRFT7Y4AD983rpsqf NJkQNQeiPj40A13tZKmW5qZMC2Z3xpHyBbfQZDmwYwnhszMkeywgVlF0dGUhmPL1A6Nw 6/vnPC8qmEpzYbi6g8ttemFDx5VJMhXaieHcxIrcP6amIRGVW+M4jD8FasbmSrLUV3En Cnvg== MIME-Version: 1.0 Received: by 10.58.252.72 with SMTP id zq8mr94725141vec.20.1357837126514; Thu, 10 Jan 2013 08:58:46 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 08:58:46 -0800 (PST) In-Reply-To: <732217576.23387031.1357825472793.JavaMail.root@inria.fr> References: <732217576.23387031.1357825472793.JavaMail.root@inria.fr> Date: Thu, 10 Jan 2013 17:58:46 +0100 Message-ID: From: Abdussalam Baryun To: Philippe Jacquet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Christopher Dearlove \(UK\)" , manet@ietf.org Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:58:48 -0000 The AODVv2 insures the loop free as described in; In draft-dymo-25, page 16 or see the message on the list; http://www.ietf.org/mail-archive/web/manet/current/msg14316.html AB On 1/10/13, Philippe Jacquet wrote: > I agree with Chris, this may lead to loops if done careless. > > This metric is the min metric: you replace the + by the min operator, the > cost of a route is the min bandwidth of the links on the route. The aim i= s > to find the route with the max bandwidth, done via an adapted Dijkstra (a= lso > usable with OLSRv2). > > The problem with this metric is that it does not give an upperbound on th= e > number of hops (indeed optimal routes may have unlimited hop count via > loops), and in general it is better to use it with a lexicographical metr= ic > (bandwidth,hop-count) so that the optimal route will be the route with th= e > min hop count among the routes with the largest bandwidth. > > Everything is computable via Dijkstra since (shortest path on links above > bandwidth threshold). > > Philippe > ----- Mail original ----- > De: "Christopher Dearlove (UK)" > =C0: manet@ietf.org, charliep@computer.org > Envoy=E9: Jeudi 10 Janvier 2013 10:50:01 > Objet: Re: [manet] #13: Supporting monotonically nondecreasing but > non-additive metrics > > Such a metric can, in general, lead to looping. Consider A, B, C, D, E in= a > ring with metric 2 on links A - B, B - C and C - D, and metric 1 on links= D > - E and E - A. Consider a packet from B routed to E. At B it is indiffere= nt > whether to go via A or C, so may pick C. At C it is indifferent whether t= o > go via B or D, so may pick B. > > Of course in that case one can add the additional rule to not send back o= n > link just arrived. But a more complicated case can send it in a longer lo= op. > You could tie-break by number of hops, but that's actually a more > complicated metric. However something like that is essential - consider a > network all of whose links have metric 1. Whether that tie-breaker is, in > general, sufficient is something not immediately obvious to me. > > And of course that's in general. A specific routing protocol may ensure t= hat > this doesn't happen. But that would also need work to prove. > > (The essential problem is that non-decreasing is not as good as > increasing.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > manet issue tracker > Sent: 09 January 2013 22:27 > To: charliep@computer.org > Cc: manet@ietf.org > Subject: [manet] #13: Supporting monotonically nondecreasing but > non-additive metrics > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > #13: Supporting monotonically nondecreasing but non-additive metrics > > There are some useful metrics that are nondecreasing but not "naturally" > additive. That is, making an additive definition for them requires > unnatural mental gymnastics. > > A good example is "1 / bandwidth". This metric is not affected by > higher-bandwidth links, but only by the link that has the least bandwidt= h > from among all the path components of the route. Strangely, this > quantity does not seem to have a commonly accepted name that I can find. > The best I can do so far is to call it the "Slowness" metric. One > could use the Slowness metric as a nondecreasing metric which still > finds the fastest route. > > Supporting such metrics in AODVv2 can be done by simply > replacing "!RteMsg.Metric + Cost(L)" by another function that > could be called "!TotalCost (!RteMsg.Metric, Cost(L))". The impact > on the specification is minor (only a few lines), and the possible > future benefit could be substantial. For !HopCount, > !TotalCost(!RteMsg.Metric,Cost(L)) is defined to be (!RteMsg.Metric + 1)= . > > -- > -----------------------------------+----------------------------------- > Reporter: charliep@computer.org | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: nondecreasing metrics > -----------------------------------+----------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From charliep@computer.org Thu Jan 10 09:59:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA57421F8A67 for ; Thu, 10 Jan 2013 09:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWXYxTeUyGrl for ; Thu, 10 Jan 2013 09:59:40 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id E5C1721F8A53 for ; Thu, 10 Jan 2013 09:59:39 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TtMPi-00045E-Lc; Thu, 10 Jan 2013 12:59:38 -0500 Message-ID: <50EF0186.5020506@computer.org> Date: Thu, 10 Jan 2013 09:59:34 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Peter_H=F6fner?= References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> In-Reply-To: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861718496c206df9ca4923ac5ea2951043350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: Rob van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:59:40 -0000 Hello Peter and all, It is well known that reactive protocols can yield non-optimal routes. I agree with your scenario that iRREP has even more such cases that can produce non-optimal routes. Thanks for showing the example. To answer your question directly: Yes, it is possible to design RREP so that incrementing sequence numbers is not always possible. And, in fact, that was done in earlier versions of DYMO. But I was not 100% certain that the design was always an improvement, and it is really important to guarantee that stale RREPs cannot cause loops. Plus, the current design is easy to understand and implement. Given earlier concerns about readability, preferring simpler designs has been an important goal for me. I am certainly open to improving the design of the sequence number incrementation, and if you have a proposal please do share it with the mailing list. If I were to make a proposal along these lines, I would specify that the AODVv2 router generating the RREP SHOULD NOT increment its sequence number unless either (i) its route table has been updated with new destinations or metrics, or (ii) its neighborhood has changed. Even that relatively loose constraint could probably be relaxed further with additional record-keeping. My understanding from previous work is that the degree of non-optimality (sometimes called the "stretch factor") is small on average, statistically speaking. I think it's typically under 10%, but this depends on numerous factors. If you have details about any statistics you may have gathered on this point, please share! Regards, Charlie P. On 1/9/2013 11:26 PM, Peter Höfner wrote: > While analysing AODVv2 we came across a potential problem: > we can show that (at least in combination with intermediate route reply) > always incrementing sequence numbers when issuing a route reply can > lead to non-optimal routes. > > A detailed example is given at > http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf > > The example does not use any unusual set-up (special topology, special > time of link breaks, etc); hence we think that this type of behaviour > can happen frequently. However, we have not done any measurements. > > Moreover, a similar example can occur without intermediate route > reply (when only the destination is allowed to answer); but that > scenario needs a dynamic topology or a message-loss during transmission. > > A solution could be to only increment sequence numbers when needed. > More precisely, the sequence number of the destination node (generating the reply) > would be set as the maximum of the current sequence number of that node and the > incremented (by 1) sequence number from the received RREQ message. > > Is there a problem with not incrementing sequence numbers all the time? > > Cheers > Peter, Rob, Marius, Wee Lum > > P.S. This mail may be relevant for ticket #6 in the MANET Trac system > > ________________________________ > > The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From charliep@computer.org Thu Jan 10 10:50:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2C921F8A4A for ; Thu, 10 Jan 2013 10:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvlPRDDm3Tmx for ; Thu, 10 Jan 2013 10:50:12 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5B21F8A45 for ; Thu, 10 Jan 2013 10:50:12 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TtNCd-0005VM-0B; Thu, 10 Jan 2013 13:50:11 -0500 Message-ID: <50EF0D5E.4010604@computer.org> Date: Thu, 10 Jan 2013 10:50:06 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Peter_H=F6fner?= References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <50EF0186.5020506@computer.org> In-Reply-To: <50EF0186.5020506@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8604938a5ab6e3d629a69929b791f989bf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: Wee Lum Tan , manet@ietf.org, Rob van Glabbeek Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:50:16 -0000 Hello folks, I made a confusing typo in my previous email. I said : > Yes, it is possible to design RREP so that incrementing sequence > numbers is not always *possible*. I should have said: Yes, it is possible to design RREP so that incrementing sequence numbers is not always *required*. Please excuse the mistake. Regards, Charlie P. On 1/10/2013 9:59 AM, Charles E. Perkins wrote: > Hello Peter and all, > > It is well known that reactive protocols can yield non-optimal routes. > I agree with your scenario that iRREP has even more such cases that > can produce non-optimal routes. Thanks for showing the example. > > To answer your question directly: > > Yes, it is possible to design RREP so that incrementing sequence > numbers is not always possible. And, in fact, that was done in earlier > versions of DYMO. But I was not 100% certain that the design was > always an improvement, and it is really important to guarantee that > stale RREPs cannot cause loops. > > Plus, the current design is easy to understand and implement. > Given earlier concerns about readability, preferring simpler designs > has been an important goal for me. > > I am certainly open to improving the design of the sequence number > incrementation, and if you have a proposal please do share it with > the mailing list. If I were to make a proposal along these lines, I > would specify that the AODVv2 router generating the RREP SHOULD > NOT increment its sequence number unless either (i) its route table > has been updated with new destinations or metrics, or (ii) its > neighborhood has changed. Even that relatively loose constraint > could probably be relaxed further with additional record-keeping. > > My understanding from previous work is that the degree of > non-optimality (sometimes called the "stretch factor") is small > on average, statistically speaking. I think it's typically under 10%, > but this depends on numerous factors. If you have details about > any statistics you may have gathered on this point, please share! > > Regards, > Charlie P. > > > > On 1/9/2013 11:26 PM, Peter Höfner wrote: >> While analysing AODVv2 we came across a potential problem: >> we can show that (at least in combination with intermediate route reply) >> always incrementing sequence numbers when issuing a route reply can >> lead to non-optimal routes. >> >> A detailed example is given at >> http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf >> >> The example does not use any unusual set-up (special topology, special >> time of link breaks, etc); hence we think that this type of behaviour >> can happen frequently. However, we have not done any measurements. >> >> Moreover, a similar example can occur without intermediate route >> reply (when only the destination is allowed to answer); but that >> scenario needs a dynamic topology or a message-loss during transmission. >> >> A solution could be to only increment sequence numbers when needed. >> More precisely, the sequence number of the destination node >> (generating the reply) >> would be set as the maximum of the current sequence number of that >> node and the >> incremented (by 1) sequence number from the received RREQ message. >> >> Is there a problem with not incrementing sequence numbers all the time? >> >> Cheers >> Peter, Rob, Marius, Wee Lum >> >> P.S. This mail may be relevant for ticket #6 in the MANET Trac system >> >> ________________________________ >> >> The information in this e-mail may be confidential and subject to >> legal professional privilege and/or copyright. National ICT Australia >> Limited accepts no liability for any damage caused by this email or >> its attachments. >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > -- Regards, Charlie P. From abdussalambaryun@gmail.com Thu Jan 10 11:08:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399921F88D6 for ; Thu, 10 Jan 2013 11:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJyr9kYLVjqE for ; Thu, 10 Jan 2013 11:08:33 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id 28C3121F88BD for ; Thu, 10 Jan 2013 11:08:33 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so663280vby.19 for ; Thu, 10 Jan 2013 11:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=f4HA5qtPEmpGroCtqKQ0BJrQ+SLUDdHmvhgKKLVuiS8=; b=aD9iCWRqmgEazUgylqJqtjpDUnu7acbTDNN+wo64msXgOBPimrSo+HS5XvPqegOOJO qUvkYGRqJecmW3F39FXy3lS5DyJBTDra/0x5k2bEH95vMNpid1la1iBiH9GkpSWJrMlm 1o/V1YZl10U8O72UKAbGIKqe/evxL62IYiR4+5v0Zygm1nOmmThec6hBzY0vh0SjTIC3 ZoT0dorq4JPxJRqhoyqyZ90ymQJphn/rCLb7QXVR6y1i0tQSYVLZJIfgjWaq7FXP7ESb bJa9dJyG7LttLRtFbdmiBZsAytvkjKkuVLzqjK6j8/QKQt2lCyWMakG9AE3RWJcX6sLO H8FQ== MIME-Version: 1.0 Received: by 10.52.76.73 with SMTP id i9mr79406316vdw.25.1357844912367; Thu, 10 Jan 2013 11:08:32 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 11:08:32 -0800 (PST) In-Reply-To: <50EF0186.5020506@computer.org> References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <50EF0186.5020506@computer.org> Date: Thu, 10 Jan 2013 20:08:32 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , =?ISO-8859-1?Q?Peter_H=F6fner?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:08:34 -0000 Hi Peter and Charlie, I don't think that a design for not incrementing SN is a better approach, and don't think the example scenarios problem was caused by the increment. The increment of SN was needed in the example. The problem was that the source updated its route twice. I don't think it was needed to update route while the cost was less, just ignore such RREP and choose better option. AB On 1/10/13, Charles E. Perkins wrote: > Hello Peter and all, > > It is well known that reactive protocols can yield non-optimal routes. > I agree with your scenario that iRREP has even more such cases that > can produce non-optimal routes. Thanks for showing the example. > > To answer your question directly: > > Yes, it is possible to design RREP so that incrementing sequence > numbers is not always possible. And, in fact, that was done in earlier > versions of DYMO. But I was not 100% certain that the design was > always an improvement, and it is really important to guarantee that > stale RREPs cannot cause loops. > > Plus, the current design is easy to understand and implement. > Given earlier concerns about readability, preferring simpler designs > has been an important goal for me. > > I am certainly open to improving the design of the sequence number > incrementation, and if you have a proposal please do share it with > the mailing list. If I were to make a proposal along these lines, I > would specify that the AODVv2 router generating the RREP SHOULD > NOT increment its sequence number unless either (i) its route table > has been updated with new destinations or metrics, or (ii) its > neighborhood has changed. Even that relatively loose constraint > could probably be relaxed further with additional record-keeping. > > My understanding from previous work is that the degree of > non-optimality (sometimes called the "stretch factor") is small > on average, statistically speaking. I think it's typically under 10%, > but this depends on numerous factors. If you have details about > any statistics you may have gathered on this point, please share! > > Regards, > Charlie P. > > > > On 1/9/2013 11:26 PM, Peter H=F6fner wrote: >> While analysing AODVv2 we came across a potential problem: >> we can show that (at least in combination with intermediate route reply) >> always incrementing sequence numbers when issuing a route reply can >> lead to non-optimal routes. >> >> A detailed example is given at >> http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf >> >> The example does not use any unusual set-up (special topology, special >> time of link breaks, etc); hence we think that this type of behaviour >> can happen frequently. However, we have not done any measurements. >> >> Moreover, a similar example can occur without intermediate route >> reply (when only the destination is allowed to answer); but that >> scenario needs a dynamic topology or a message-loss during transmission. >> >> A solution could be to only increment sequence numbers when needed. >> More precisely, the sequence number of the destination node (generating >> the reply) >> would be set as the maximum of the current sequence number of that node >> and the >> incremented (by 1) sequence number from the received RREQ message. >> >> Is there a problem with not incrementing sequence numbers all the time? >> >> Cheers >> Peter, Rob, Marius, Wee Lum >> >> P.S. This mail may be relevant for ticket #6 in the MANET Trac system >> >> ________________________________ >> >> The information in this e-mail may be confidential and subject to legal >> professional privilege and/or copyright. National ICT Australia Limited >> accepts no liability for any damage caused by this email or its >> attachments. >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Jan 10 11:20:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F218621F8920 for ; Thu, 10 Jan 2013 11:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FxVxAk6RZvW for ; Thu, 10 Jan 2013 11:20:56 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8575A21F8864 for ; Thu, 10 Jan 2013 11:20:55 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id n11so684705vch.16 for ; Thu, 10 Jan 2013 11:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xapv5KI738iGfc+dluWuf20Vn0xh+jZnSFYde5yrgPU=; b=FHNFrl++7kf+UskFgEzw3B0Cj+lGW+k+9isFZQ2L0/D+/t8GBnujOJ0pB5Yq0qnvFP cy3r2P6cfEZBFAwZcYwSGtQTOOvoTo+5co4uVkIOhIhl2wBO/Is9RvTDx1Rh06mEbANl fHOPHI5fxhz8bJ7ofqh+YUFGIBpnOH8bewGpnNl/Bo75bRGaYRoti+haMK4FOPGhbWAE kWLKamhZS12wMoipwuVzL0Ag53yLlKlaHUi8SZUhrQPRlezSWpmLCsFcDdz2iFHrSFhc 4uvN4hJ+v1Y1hsAP6IoFUfVY9CHB2iE9YtRsGZyLHVL+05+ZeFhdq4xdszxpnBbgq+fY P02w== MIME-Version: 1.0 Received: by 10.52.21.179 with SMTP id w19mr80697861vde.55.1357845654847; Thu, 10 Jan 2013 11:20:54 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 11:20:54 -0800 (PST) In-Reply-To: References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <50EF0186.5020506@computer.org> Date: Thu, 10 Jan 2013 20:20:54 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , =?ISO-8859-1?Q?Peter_H=F6fner?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:20:57 -0000 In other words, if we take the subject question, as; When the increment SN not needed, then the source node will ignore such increment (because not needed), then the source will not update its route, from the example given, therefore, will still take optimum route. AB > > > On 1/10/13, Charles E. Perkins wrote: >> Hello Peter and all, >> >> It is well known that reactive protocols can yield non-optimal routes. >> I agree with your scenario that iRREP has even more such cases that >> can produce non-optimal routes. Thanks for showing the example. >> >> To answer your question directly: >> >> Yes, it is possible to design RREP so that incrementing sequence >> numbers is not always possible. And, in fact, that was done in earlier >> versions of DYMO. But I was not 100% certain that the design was >> always an improvement, and it is really important to guarantee that >> stale RREPs cannot cause loops. >> >> Plus, the current design is easy to understand and implement. >> Given earlier concerns about readability, preferring simpler designs >> has been an important goal for me. >> >> I am certainly open to improving the design of the sequence number >> incrementation, and if you have a proposal please do share it with >> the mailing list. If I were to make a proposal along these lines, I >> would specify that the AODVv2 router generating the RREP SHOULD >> NOT increment its sequence number unless either (i) its route table >> has been updated with new destinations or metrics, or (ii) its >> neighborhood has changed. Even that relatively loose constraint >> could probably be relaxed further with additional record-keeping. >> >> My understanding from previous work is that the degree of >> non-optimality (sometimes called the "stretch factor") is small >> on average, statistically speaking. I think it's typically under 10%, >> but this depends on numerous factors. If you have details about >> any statistics you may have gathered on this point, please share! >> >> Regards, >> Charlie P. >> >> >> >> On 1/9/2013 11:26 PM, Peter H=F6fner wrote: >>> While analysing AODVv2 we came across a potential problem: >>> we can show that (at least in combination with intermediate route reply= ) >>> always incrementing sequence numbers when issuing a route reply can >>> lead to non-optimal routes. >>> >>> A detailed example is given at >>> http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf >>> >>> The example does not use any unusual set-up (special topology, special >>> time of link breaks, etc); hence we think that this type of behaviour >>> can happen frequently. However, we have not done any measurements. >>> >>> Moreover, a similar example can occur without intermediate route >>> reply (when only the destination is allowed to answer); but that >>> scenario needs a dynamic topology or a message-loss during transmission= . >>> >>> A solution could be to only increment sequence numbers when needed. >>> More precisely, the sequence number of the destination node (generating >>> the reply) >>> would be set as the maximum of the current sequence number of that node >>> and the >>> incremented (by 1) sequence number from the received RREQ message. >>> >>> Is there a problem with not incrementing sequence numbers all the time? >>> >>> Cheers >>> Peter, Rob, Marius, Wee Lum >>> >>> P.S. This mail may be relevant for ticket #6 in the MANET Trac system >>> >>> ________________________________ >>> >>> The information in this e-mail may be confidential and subject to legal >>> professional privilege and/or copyright. National ICT Australia Limited >>> accepts no liability for any damage caused by this email or its >>> attachments. >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > From charliep@computer.org Thu Jan 10 11:25:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F6421F8A0D for ; Thu, 10 Jan 2013 11:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xfefgMb-EDy for ; Thu, 10 Jan 2013 11:25:00 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEF821F8A4A for ; Thu, 10 Jan 2013 11:25:00 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TtNkI-0004it-Es; Thu, 10 Jan 2013 14:24:58 -0500 Message-ID: <50EF1586.9060405@computer.org> Date: Thu, 10 Jan 2013 11:24:54 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge , Joseph Macker References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> In-Reply-To: <50C98640.7010001@fkie.fraunhofer.de> Content-Type: multipart/alternative; boundary="------------070206070102070904000104" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad860bd004860642e00258cda9c8f13c9908350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:25:01 -0000 This is a multi-part message in MIME format. --------------070206070102070904000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Henning (and Joe), I will try to summarize the Gateway discussion for the Issue Tracker. Joe said, on Dec. 8: > while gatewaying reactive is perhaps more difficult and there may > be multiple strategies i also feel something should be in the base > specification It could be argued that the IAR description within AODVv2 is enough for this purpose. I've already said that I think the issue is nontrivial. And, again, while I am not hoping to take responsibility for creating additional specification in the reactive document, I am (as always) happy to insert any text that you and/or the rest of the WG agrees is required. I need to mention two things: - If the gateway advertises a default route [e.g. 0/0], then any AODVv2 router receiving it won't do Route Discovery. The likely result will be that the gateway will become an intermediate routing point for every route in the network. To me that sounds like a terribly nonscalable design. - Any network that attaches to the Internet these days needs to have various policy knobs. Do you suggest that we simply punt? Do we make a normative reference for some other protocol that the IAR (or "Internet Gateway", or ...) MUST implement? Manet gateways are not an issue specific to reactive protocols. Any such specification ought to apply to both reactive and proactive protocols (such as discussed in the document I submitted earlier for discussion). Did you have any comments about that? Regards, Charlie P. On 12/12/2012 11:39 PM, Henning Rogge wrote: > On 12/12/2012 07:39 PM, Charles E. Perkins wrote: >> >> Hello Chris, >> >> Yes, if the WG decides to put in something about gateways in the >> document, that will require more work. I don't know if you had >> a look at the expired document that I posted a few days ago on >> the subject of gateways, but the discussion on the list also in my >> opinion shows that the matter is not settled for OLSRv2 either. >> I'm sure you can sift through the emails and find various points >> that are not settled and still worthy of discussion. > > The difference is that OLSRv2 (and OLSRv1) contains the tool to handle > all kind of network situations be propagating any kind of prefix > through the network. This is the basis of internet uplinks and > attached networks. > > AODVv2 does not. > > Henning Rogge > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------070206070102070904000104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Henning (and Joe),

I will try to summarize the Gateway discussion for the Issue Tracker.

Joe said, on Dec. 8:

while gatewaying reactive is perhaps more difficult and there may
be multiple strategies i also feel something should be in the base
specification

It could be argued that the IAR description within AODVv2 is enough
for this purpose.  I've already said that I think the issue is nontrivial.
And, again, while I am not hoping to take responsibility for creating
additional specification in the reactive document, I am (as always)
happy to insert any text that you and/or the rest of the WG agrees
is required.

I need to mention two things:

- If the gateway advertises a default route [e.g. 0/0], then
  any AODVv2 router receiving it won't do Route Discovery.
  The likely result will be that the gateway will become an
  intermediate routing point for every route in the network.
  To me that sounds like a terribly nonscalable design.

- Any network that attaches to the Internet these days needs
   to have various policy knobs.  Do you suggest that we simply
   punt?  Do we make a normative reference for some other
   protocol that the IAR (or "Internet Gateway", or ...)
   MUST implement?


Manet gateways are not an issue specific to reactive protocols.
Any such specification ought to apply to both reactive and
proactive protocols (such as discussed in the document I
submitted earlier for discussion).  Did you have any comments
about that?

Regards,
Charlie P.


On 12/12/2012 11:39 PM, Henning Rogge wrote:
On 12/12/2012 07:39 PM, Charles E. Perkins wrote:

Hello Chris,

Yes, if the WG decides to put in something about gateways in the
document, that will require more work.  I don't know if you had
a look at the expired document that I posted a few days ago on
the subject of gateways, but the discussion on the list also in my
opinion shows that the matter is not settled for OLSRv2 either.
I'm sure you can sift through the emails and find various points
that are not settled and still worthy of discussion.

The difference is that OLSRv2 (and OLSRv1) contains the tool to handle all kind of network situations be propagating any kind of prefix through the network. This is the basis of internet uplinks and attached networks.

AODVv2 does not.

Henning Rogge 




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------070206070102070904000104-- From charliep@computer.org Thu Jan 10 11:37:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FEB21F8613 for ; Thu, 10 Jan 2013 11:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FAyFSuB1p0U for ; Thu, 10 Jan 2013 11:37:20 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB821F8609 for ; Thu, 10 Jan 2013 11:37:20 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TtNwE-0007Wo-N3; Thu, 10 Jan 2013 14:37:18 -0500 Message-ID: <50EF186A.1050603@computer.org> Date: Thu, 10 Jan 2013 11:37:14 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <50EF0186.5020506@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f31cf196f0dfa2a1a7adb2cf5c468159350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet@ietf.org Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:37:24 -0000 Hello Abdussalam, Current design requires that the route update with the most recent Sequence Number is required to be used. How can one ignore such an RREP? Or perhaps I am misunderstanding your suggestion...? Any such proposal has to be considered from the standpoint of trading off route optimality versus volume of signaling (while maintaining loop-freedom). Regards, Charlie P. On 1/10/2013 11:08 AM, Abdussalam Baryun wrote: > Hi Peter and Charlie, > > I don't think that a design for not incrementing SN is a better > approach, and don't think the example scenarios problem was caused by > the increment. The increment of SN was needed in the example. The > problem was that the source updated its route twice. I don't think it > was needed to update route while the cost was less, just ignore such > RREP and choose better option. > > AB > > > On 1/10/13, Charles E. Perkins wrote: >> Hello Peter and all, >> >> It is well known that reactive protocols can yield non-optimal routes. >> I agree with your scenario that iRREP has even more such cases that >> can produce non-optimal routes. Thanks for showing the example. >> >> To answer your question directly: >> >> Yes, it is possible to design RREP so that incrementing sequence >> numbers is not always possible. And, in fact, that was done in earlier >> versions of DYMO. But I was not 100% certain that the design was >> always an improvement, and it is really important to guarantee that >> stale RREPs cannot cause loops. >> >> Plus, the current design is easy to understand and implement. >> Given earlier concerns about readability, preferring simpler designs >> has been an important goal for me. >> >> I am certainly open to improving the design of the sequence number >> incrementation, and if you have a proposal please do share it with >> the mailing list. If I were to make a proposal along these lines, I >> would specify that the AODVv2 router generating the RREP SHOULD >> NOT increment its sequence number unless either (i) its route table >> has been updated with new destinations or metrics, or (ii) its >> neighborhood has changed. Even that relatively loose constraint >> could probably be relaxed further with additional record-keeping. >> >> My understanding from previous work is that the degree of >> non-optimality (sometimes called the "stretch factor") is small >> on average, statistically speaking. I think it's typically under 10%, >> but this depends on numerous factors. If you have details about >> any statistics you may have gathered on this point, please share! >> >> Regards, >> Charlie P. >> >> >> >> On 1/9/2013 11:26 PM, Peter Höfner wrote: >>> While analysing AODVv2 we came across a potential problem: >>> we can show that (at least in combination with intermediate route reply) >>> always incrementing sequence numbers when issuing a route reply can >>> lead to non-optimal routes. >>> >>> A detailed example is given at >>> http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf >>> >>> The example does not use any unusual set-up (special topology, special >>> time of link breaks, etc); hence we think that this type of behaviour >>> can happen frequently. However, we have not done any measurements. >>> >>> Moreover, a similar example can occur without intermediate route >>> reply (when only the destination is allowed to answer); but that >>> scenario needs a dynamic topology or a message-loss during transmission. >>> >>> A solution could be to only increment sequence numbers when needed. >>> More precisely, the sequence number of the destination node (generating >>> the reply) >>> would be set as the maximum of the current sequence number of that node >>> and the >>> incremented (by 1) sequence number from the received RREQ message. >>> >>> Is there a problem with not incrementing sequence numbers all the time? >>> >>> Cheers >>> Peter, Rob, Marius, Wee Lum >>> >>> P.S. This mail may be relevant for ticket #6 in the MANET Trac system >>> >>> ________________________________ >>> >>> The information in this e-mail may be confidential and subject to legal >>> professional privilege and/or copyright. National ICT Australia Limited >>> accepts no liability for any damage caused by this email or its >>> attachments. >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From abdussalambaryun@gmail.com Thu Jan 10 13:19:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DDF21F8842 for ; Thu, 10 Jan 2013 13:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-cB--2nbufb for ; Thu, 10 Jan 2013 13:19:35 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8B221F8716 for ; Thu, 10 Jan 2013 13:19:35 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id fa15so807092vbb.15 for ; Thu, 10 Jan 2013 13:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x5ju+h9preGDPmvvwa4D4uo1yEGjHDgY+4ybONLb4wE=; b=ZCgMFOmXll9lMW57NOoHjqMlsPf9pSpiFXqlk2KNb6+3kIoajNBh4bUMYnOPYnsq+b CcgIeQt4zpg72xiqEmmL8Fwf2vIDV9nzAB26CE/toJJYruGxiJWdOF3uwBfhzz+TZ8IZ M+8JkXaMVMgmip7sgVViDYoN9rtCBNZ3ybN2TQi03/z0wcqvKVNyOeFREStlOZZiZRfU z/7kitnvT0pqCTtYnZRGb65Lkx/e8ZvEK3z1/OcLtiO8khNfe1YWqo97b+8pqnA/1ev5 ktykma9QBTvbiN9nbFR+N/kUUafqQdtGEero1d09Eae1o3F/enebfXCTxbw11+wYOSZ1 hC5g== MIME-Version: 1.0 Received: by 10.58.243.166 with SMTP id wz6mr94996310vec.28.1357852774355; Thu, 10 Jan 2013 13:19:34 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 13:19:34 -0800 (PST) In-Reply-To: <50EF186A.1050603@computer.org> References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <50EF0186.5020506@computer.org> <50EF186A.1050603@computer.org> Date: Thu, 10 Jan 2013 22:19:34 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:19:36 -0000 Hello Charlie, I agree with current design. Regarding the example or proposal of subject, I want it to be required route update while required increment SN, and if not required increment then may not required update. Please advise if make sense, if not then maybe I will need to run test, AB On 1/10/13, Charles E. Perkins wrote: > Hello Abdussalam, > > Current design requires that the route update with the most > recent Sequence Number is required to be used. How can > one ignore such an RREP? > > Or perhaps I am misunderstanding your suggestion...? > > Any such proposal has to be considered from the standpoint > of trading off route optimality versus volume of signaling > (while maintaining loop-freedom). > > Regards, > Charlie P. > > > On 1/10/2013 11:08 AM, Abdussalam Baryun wrote: >> Hi Peter and Charlie, >> >> I don't think that a design for not incrementing SN is a better >> approach, and don't think the example scenarios problem was caused by >> the increment. The increment of SN was needed in the example. The >> problem was that the source updated its route twice. I don't think it >> was needed to update route while the cost was less, just ignore such >> RREP and choose better option. >> >> AB >> >> >> On 1/10/13, Charles E. Perkins wrote: >>> Hello Peter and all, >>> >>> It is well known that reactive protocols can yield non-optimal routes. >>> I agree with your scenario that iRREP has even more such cases that >>> can produce non-optimal routes. Thanks for showing the example. >>> >>> To answer your question directly: >>> >>> Yes, it is possible to design RREP so that incrementing sequence >>> numbers is not always possible. And, in fact, that was done in earlier >>> versions of DYMO. But I was not 100% certain that the design was >>> always an improvement, and it is really important to guarantee that >>> stale RREPs cannot cause loops. >>> >>> Plus, the current design is easy to understand and implement. >>> Given earlier concerns about readability, preferring simpler designs >>> has been an important goal for me. >>> >>> I am certainly open to improving the design of the sequence number >>> incrementation, and if you have a proposal please do share it with >>> the mailing list. If I were to make a proposal along these lines, I >>> would specify that the AODVv2 router generating the RREP SHOULD >>> NOT increment its sequence number unless either (i) its route table >>> has been updated with new destinations or metrics, or (ii) its >>> neighborhood has changed. Even that relatively loose constraint >>> could probably be relaxed further with additional record-keeping. >>> >>> My understanding from previous work is that the degree of >>> non-optimality (sometimes called the "stretch factor") is small >>> on average, statistically speaking. I think it's typically under 10%, >>> but this depends on numerous factors. If you have details about >>> any statistics you may have gathered on this point, please share! >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 1/9/2013 11:26 PM, Peter H=F6fner wrote: >>>> While analysing AODVv2 we came across a potential problem: >>>> we can show that (at least in combination with intermediate route >>>> reply) >>>> always incrementing sequence numbers when issuing a route reply can >>>> lead to non-optimal routes. >>>> >>>> A detailed example is given at >>>> http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf >>>> >>>> The example does not use any unusual set-up (special topology, special >>>> time of link breaks, etc); hence we think that this type of behaviour >>>> can happen frequently. However, we have not done any measurements. >>>> >>>> Moreover, a similar example can occur without intermediate route >>>> reply (when only the destination is allowed to answer); but that >>>> scenario needs a dynamic topology or a message-loss during >>>> transmission. >>>> >>>> A solution could be to only increment sequence numbers when needed. >>>> More precisely, the sequence number of the destination node (generatin= g >>>> the reply) >>>> would be set as the maximum of the current sequence number of that nod= e >>>> and the >>>> incremented (by 1) sequence number from the received RREQ message. >>>> >>>> Is there a problem with not incrementing sequence numbers all the time= ? >>>> >>>> Cheers >>>> Peter, Rob, Marius, Wee Lum >>>> >>>> P.S. This mail may be relevant for ticket #6 in the MANET Trac system >>>> >>>> ________________________________ >>>> >>>> The information in this e-mail may be confidential and subject to lega= l >>>> professional privilege and/or copyright. National ICT Australia Limite= d >>>> accepts no liability for any damage caused by this email or its >>>> attachments. >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From Marc.Mosko@parc.com Thu Jan 10 14:01:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA7121F87DF for ; Thu, 10 Jan 2013 14:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMu9aWHJiY4U for ; Thu, 10 Jan 2013 14:01:28 -0800 (PST) Received: from omega.xerox.com (omega.xerox.com [13.1.64.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9A90A21F87D3 for ; Thu, 10 Jan 2013 14:01:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by omega.xerox.com (Postfix) with ESMTP id 06EF22540CF; Thu, 10 Jan 2013 14:01:28 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at parc.com Received: from omega.xerox.com ([127.0.0.1]) by localhost (omega.xerox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGxQmBq4FDFd; Thu, 10 Jan 2013 14:01:27 -0800 (PST) Received: from exchangehub.parc.xerox.com (e2010hub1.parc.xerox.com [13.2.12.22]) by omega.xerox.com (Postfix) with ESMTPS id CC1792540AE; Thu, 10 Jan 2013 14:01:27 -0800 (PST) Received: from E2010DAG5.corp.ad.parc.com ([fe80::3d0b:7158:aec4:e05e]) by e2010hub1.corp.ad.parc.com ([fe80::8945:a39d:8c92:373f%12]) with mapi id 14.02.0328.009; Thu, 10 Jan 2013 14:01:27 -0800 From: To: , Thread-Topic: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. Thread-Index: AQHN734Jc3RCiuted0e/OXalco7bcQ== Date: Thu, 10 Jan 2013 22:01:27 +0000 Message-ID: <7CB233D07722374DB3A5C088E1E8088B363FFFBE@e2010dag5.corp.ad.parc.com> In-Reply-To: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [13.4.12.169] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5A262688FCF95C4E94031D3671C27EAC@ad.parc.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 10 Jan 2013 14:08:06 -0800 Cc: WeeLum.Tan@nicta.com.au, Robert.vanGlabbeek@nicta.com.au Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 22:01:30 -0000 Peter, In your diagram (c), node j does not increment its sequence number for d. Intermediate RREP (iRREP) follow draft-perkins-irrep, not draft-ietf-manet-dymo. It would be a bad thing for a node to have an active route with a sequence number higher than the destination's own seqnum. All active paths must be well-ordered according to 5.2.1. Also, node j, according to draft-perkins-irrep, should send a uRREP to d in addition to the iRREP to s. This would build a shortest-path d->j->s reverse path that would not be overridden by the s->i->=8A->d rreq. One would end up with an asymmetric route. I believe that in an AODV-style network, the destination should always increment its seqnum if they are equal. Otherwise, you might frequently end up violating 5.2.1(2) and have to drop the RREP. One typically uses an expanding ring search to try and find a near by intermediate node with a valid route. The size of the expanding ring search will influence the amount of route stretch. If the nearby search fails, you're probably better off doing a destination-only rreq than flooding the whole network with an anybody-can-reply rreq. In your example, if node s had node a TTL=3D3 RREQ before doing a destination-only RREQ, it would have calculated the correct shortest path s->j->d. If it had done a TTL=3D4 RREQ, it would have found the longer path s->i->=8A->d a= nd be happy with the slack because it asked for it. The observation that incrementing sequence numbers prior to RREQ causes inefficient pathfinding is an old issue. The paper, for instance, "A new approach to on-demand loop-free routing in ad hoc networks" (Garcia-Luna-Aceves, Mosko, Perkins, 2003) [http://dl.acm.org/citation.cfm?id=3D872043] is based on the observation that increasing the sequence number essentially invalidates your successors and results in the destination being the only node that can reply. In this paper, the sequence number is used as a last-resort reset to paths. As per your example, the destination only increases its sequence number if the RREQ carried the current sequence number, so in your case d would not increment because the RREQ along the s->i->=8A->d pat= h carried seqnum 1 and d was was seqnum 2. Therefore, the RREPs at s would both be seqnum 2 and s would use the shorter path. Marc Mosko On 1/9/13 11:26 PM, "Peter H=F6fner" wrote: >While analysing AODVv2 we came across a potential problem: >we can show that (at least in combination with intermediate route reply) >always incrementing sequence numbers when issuing a route reply can >lead to non-optimal routes. > >A detailed example is given at >http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf > >The example does not use any unusual set-up (special topology, special >time of link breaks, etc); hence we think that this type of behaviour >can happen frequently. However, we have not done any measurements. > >Moreover, a similar example can occur without intermediate route >reply (when only the destination is allowed to answer); but that >scenario needs a dynamic topology or a message-loss during transmission. > >A solution could be to only increment sequence numbers when needed. >More precisely, the sequence number of the destination node (generating >the reply) >would be set as the maximum of the current sequence number of that node >and the >incremented (by 1) sequence number from the received RREQ message. > >Is there a problem with not incrementing sequence numbers all the time? > >Cheers >Peter, Rob, Marius, Wee Lum > >P.S. This mail may be relevant for ticket #6 in the MANET Trac system > >________________________________ > >The information in this e-mail may be confidential and subject to legal >professional privilege and/or copyright. National ICT Australia Limited >accepts no liability for any damage caused by this email or its >attachments. > From abdussalambaryun@gmail.com Thu Jan 10 16:16:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3F21F86D3 for ; Thu, 10 Jan 2013 16:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKM3bO22Brkz for ; Thu, 10 Jan 2013 16:16:00 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id E308321F8528 for ; Thu, 10 Jan 2013 16:15:59 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so912525vbb.24 for ; Thu, 10 Jan 2013 16:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=acYt22EyLyrAMZouLEblJf4edO81NQgXuK0S67C0Fxk=; b=VyvS/aO4msyx+eeRrRgKIbho1O0btNzOcJB/yPGZzSmJh/9gFSDUlzk7WwvWF8Ukf+ DEG/yyHk+uUvU57RIjjmBeWSf54v4bPoUFS9Ei8Rp9bHb7fyuu/vieF6yK5xd1xNUroK BMKXqdbcBOD4/gtyKmfiAIU/C4V0unv7P7FFW9zNuulQB/KW4byVl1Ylrmn4aL7l2V/w UDsva9jN3LWl+epJ2IHORJA2KbO01i3pdzQARlcPKq04jASdyuSZ2dnELwVj3Buyfi65 5zyl4SFi+ioW/TXFoTmmiCWcxK9qFyRWkFKYUVLRv8BHYcyHLOh1DuDiALLB+MLS44MA tiQg== MIME-Version: 1.0 Received: by 10.52.76.73 with SMTP id i9mr80074867vdw.25.1357863359095; Thu, 10 Jan 2013 16:15:59 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 16:15:58 -0800 (PST) In-Reply-To: <7CB233D07722374DB3A5C088E1E8088B363FFFBE@e2010dag5.corp.ad.parc.com> References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <7CB233D07722374DB3A5C088E1E8088B363FFFBE@e2010dag5.corp.ad.parc.com> Date: Fri, 11 Jan 2013 01:15:58 +0100 Message-ID: From: Abdussalam Baryun To: Marc.Mosko@parc.com, "charliep@computer.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Robert.vanGlabbeek@nicta.com.au, manet@ietf.org, WeeLum.Tan@nicta.com.au Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 00:16:01 -0000 Hi Yes I agree, I also think that the use in the example of iRREP while it is optional in AODVv2, so by default the draft-25 only RREP generated by d. if you think statement not correct please advise, AB On 1/10/13, Marc.Mosko@parc.com wrote: > Peter, > > In your diagram (c), node j does not increment its sequence number for d. > Intermediate RREP (iRREP) follow draft-perkins-irrep, not > draft-ietf-manet-dymo. It would be a bad thing for a node to have an > active route with a sequence number higher than the destination's own > seqnum. All active paths must be well-ordered according to 5.2.1. > > Also, node j, according to draft-perkins-irrep, should send a uRREP to d > in addition to the iRREP to s. This would build a shortest-path d->j->s > reverse path that would not be overridden by the s->i->=C5=A0->d rreq. O= ne > would end up with an asymmetric route. I believe that in an AODV-style > network, the destination should always increment its seqnum if they are > equal. Otherwise, you might frequently end up violating 5.2.1(2) and hav= e > to drop the RREP. > > One typically uses an expanding ring search to try and find a near by > intermediate node with a valid route. The size of the expanding ring > search will influence the amount of route stretch. If the nearby search > fails, you're probably better off doing a destination-only rreq than > flooding the whole network with an anybody-can-reply rreq. In your > example, if node s had node a TTL=3D3 RREQ before doing a destination-onl= y > RREQ, it would have calculated the correct shortest path s->j->d. If it > had done a TTL=3D4 RREQ, it would have found the longer path s->i->=C5=A0= ->d and > be happy with the slack because it asked for it. > > The observation that incrementing sequence numbers prior to RREQ causes > inefficient pathfinding is an old issue. The paper, for instance, "A new > approach to on-demand loop-free routing in ad hoc networks" > (Garcia-Luna-Aceves, Mosko, Perkins, 2003) > [http://dl.acm.org/citation.cfm?id=3D872043] is based on the observation > that increasing the sequence number essentially invalidates your > successors and results in the destination being the only node that can > reply. In this paper, the sequence number is used as a last-resort reset > to paths. As per your example, the destination only increases its > sequence number if the RREQ carried the current sequence number, so in > your case d would not increment because the RREQ along the s->i->=C5=A0->= d path > carried seqnum 1 and d was was seqnum 2. Therefore, the RREPs at s would > both be seqnum 2 and s would use the shorter path. > > Marc Mosko > > On 1/9/13 11:26 PM, "Peter H=C3=B6fner" wrot= e: > >>While analysing AODVv2 we came across a potential problem: >>we can show that (at least in combination with intermediate route reply) >>always incrementing sequence numbers when issuing a route reply can >>lead to non-optimal routes. >> >>A detailed example is given at >>http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN.pdf >> >>The example does not use any unusual set-up (special topology, special >>time of link breaks, etc); hence we think that this type of behaviour >>can happen frequently. However, we have not done any measurements. >> >>Moreover, a similar example can occur without intermediate route >>reply (when only the destination is allowed to answer); but that >>scenario needs a dynamic topology or a message-loss during transmission. >> >>A solution could be to only increment sequence numbers when needed. >>More precisely, the sequence number of the destination node (generating >>the reply) >>would be set as the maximum of the current sequence number of that node >>and the >>incremented (by 1) sequence number from the received RREQ message. >> >>Is there a problem with not incrementing sequence numbers all the time? >> >>Cheers >>Peter, Rob, Marius, Wee Lum >> >>P.S. This mail may be relevant for ticket #6 in the MANET Trac system >> >>________________________________ >> >>The information in this e-mail may be confidential and subject to legal >>professional privilege and/or copyright. National ICT Australia Limited >>accepts no liability for any damage caused by this email or its >>attachments. >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Jan 10 16:27:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FB21F86E8 for ; Thu, 10 Jan 2013 16:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ArqD9L9OZV for ; Thu, 10 Jan 2013 16:27:00 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 322F821F86AC for ; Thu, 10 Jan 2013 16:27:00 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so948362vcb.15 for ; Thu, 10 Jan 2013 16:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JvExvbYWKTFn4T02Q4EtrZG8uT1lQ8Tn5FXam9HTWKQ=; b=azhZjrI1Aa+ox/rcNO7uUcR9/zDNHMhFoY0hIlxyJPtiVXmFoDwp8NarkD7vB+XnSB FHCaR6/SN0YE/0/+8fMqfdlWeLt8ilhztfL3uVkHykJa6RNNAeNq+3QfmHiAUeQvfzEg IzxJGM9WWl5TNqveV53mG4WEJH4kJrzbYeO8uhtn1Iu+nfDMcFzNShvXjYBjl3nc2ynQ /2jjJAgtHr+++tvdbxfLOiP6Dk66m1wV0OEkDmuUD/DAzRSLmtVmFyLmjee8xER7ncHt W5LbnVopLbK8J7DqdeF1nd7EhsFu1SjUaOgwfS3LZq4oebsHGXryJJLuJoVwVE7VJHcT Tx/A== MIME-Version: 1.0 Received: by 10.58.243.166 with SMTP id wz6mr95448757vec.28.1357864019326; Thu, 10 Jan 2013 16:26:59 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 10 Jan 2013 16:26:59 -0800 (PST) In-Reply-To: <50EF1586.9060405@computer.org> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> Date: Fri, 11 Jan 2013 01:26:59 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 00:27:01 -0000 Hi Charlie, question and comment below in line; On 1/10/13, Charles E. Perkins wrote: > Manet gateways are not an issue specific to reactive protocols. > Any such specification ought to apply to both reactive and > proactive protocols Yes this what I suggested as well, a separate work for gateway of manet routing, >(such as discussed in the document I > submitted earlier for discussion). Did you have any comments > about that? Which document you refer to? please give me name and date, AB From charliep@computer.org Thu Jan 10 17:36:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9021F88E4 for ; Thu, 10 Jan 2013 17:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y8bZXp0EcZs for ; Thu, 10 Jan 2013 17:36:09 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id EB62F21F88D1 for ; Thu, 10 Jan 2013 17:36:08 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TtTXT-0004jJ-SE; Thu, 10 Jan 2013 20:36:08 -0500 Message-ID: <50EF6C81.6080604@computer.org> Date: Thu, 10 Jan 2013 17:36:01 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c3084bae553b19d85ee12cc8117654b4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 01:36:09 -0000 Hello Abdussalam, On 1/10/2013 4:26 PM, Abdussalam Baryun wrote: > (such as discussed in the document I > submitted earlier for discussion). Did you have any comments > about that? > Which document you refer to? please give me name and date, Here is the information, which I sent out to the [manet] mailing list on Dec. 10... > we had quite a lot of discussion about > the gateway possibilities several years ago. Here's an old draft (that > does work) from Ryuji: > http://tools.ietf.org/id/draft-wakikawa-manet-globalv6-05.txt -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Thu Jan 10 23:03:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D408A21F8A3E for ; Thu, 10 Jan 2013 23:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGNU741IP5co for ; Thu, 10 Jan 2013 23:03:14 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5632B21F8A27 for ; Thu, 10 Jan 2013 23:03:13 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TtYdy-0002DI-OZ; Fri, 11 Jan 2013 08:03:10 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TtYdy-0004Va-Ls; Fri, 11 Jan 2013 08:03:10 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 11 Jan 2013 08:03:10 +0100 Message-ID: <50EFB929.3000901@fkie.fraunhofer.de> Date: Fri, 11 Jan 2013 08:03:05 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles E. Perkins" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> In-Reply-To: <50EE70F0.2020604@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020505030703030408010305" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16464/Fri Jan 11 05:39:23 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e2b21d81e24158e5c3d75098b3c9c024 Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:03:19 -0000 --------------ms020505030703030408010305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/10/2013 08:42 AM, Charles E. Perkins wrote: > Hello Henning, > > I'll put the issue on the Issue Tracker tomorrow. > > However, there have been many protocols using positional information > for lists (of addresses, etc) without impairment of extensibility. > This is especially true when extensions go at the end. Do you have > any particular example in mind where RFC 5444 somehow creates > a problem with this? With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because=20 I can just add whatever I want to the protocol message, as long as I use = new TLVs. New addresses? No problem, regardless on the position. New TLVs on existing addresses? No problem too. Why use a pure TLV format if we put parts of the information into the=20 order and structure of the format and do NOT use TLVs for it? The restriction of the order of addresses and the mandatory split into=20 multiple address blocks is also a problem for address compression. The=20 order and split have a huge influence on the compression efficiency,=20 demanding a specific split/order will make AODVv2 messages larger in=20 some cases. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020505030703030408010305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTEwNzAzMDhaMCMGCSqGSIb3DQEJBDEWBBRiFkbkqTm8IWdVUmr2odVvcrVK3zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEASpsVvza9/LKzTauHhRb+GHPsQG/2Gw8MNsdR/GAgP0Qj Dws9DsI8C8uXjBPWbsBmVw/zqnmv003pGyBvMzGkT3kfhhCm+alobaRVXnsf5+V3Mr9SwEJ+ 4kU0h4XY5vytiqh4H6d8HV9Tt1nqw2MzCjKaMTrDp+wmCJPvq4ytPQiK5W1aWRSXMum+Di9F UVFUPIYbDDjdVKE+EyqzIhCcIr0p/K/Xw8sPUIBlDeUHnqZkKYGabPgH3kyxH/dzjBK0QP33 K7SZlcX87OB3qDOf4XobSXuAeC+KbfmTCc6uNt7X8vWqTtNg2lrN9aDyN5HK/3IiO3hVN+lY 60a+R68hPwAAAAAAAA== --------------ms020505030703030408010305-- From henning.rogge@fkie.fraunhofer.de Thu Jan 10 23:10:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60D521F8A96 for ; Thu, 10 Jan 2013 23:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1QK0oOITgXm for ; Thu, 10 Jan 2013 23:10:21 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8C21F8AA6 for ; Thu, 10 Jan 2013 23:10:20 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TtYkh-00041D-Gb; Fri, 11 Jan 2013 08:10:07 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TtYkh-0004k4-Do; Fri, 11 Jan 2013 08:10:07 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 11 Jan 2013 08:10:07 +0100 Message-ID: <50EFBACE.3040104@fkie.fraunhofer.de> Date: Fri, 11 Jan 2013 08:10:06 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles E. Perkins" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> In-Reply-To: <50EF1586.9060405@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010309050205070508030206" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16464/Fri Jan 11 05:39:23 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8318846d41f6f18a0ab4cdd00a4712ab Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:10:23 -0000 --------------ms010309050205070508030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/10/2013 08:24 PM, Charles E. Perkins wrote: > > Hello Henning (and Joe), > > I will try to summarize the Gateway discussion for the Issue Tracker. > > Joe said, on Dec. 8: > >> while gatewaying reactive is perhaps more difficult and there may >> be multiple strategies i also feel something should be in the base >> specification > > It could be argued that the IAR description within AODVv2 is enough > for this purpose. I've already said that I think the issue is nontrivi= al. > And, again, while I am not hoping to take responsibility for creating > additional specification in the reactive document, I am (as always) > happy to insert any text that you and/or the rest of the WG agrees > is required. > > I need to mention two things: > > - If the gateway advertises a default route [e.g. 0/0], then > any AODVv2 router receiving it won't do Route Discovery. > The likely result will be that the gateway will become an > intermediate routing point for every route in the network. > To me that sounds like a terribly nonscalable design. One way to resolve the problem of the "default route" would be to=20 restrict the addresses of the MANET to a certain prefix and install a=20 blackhole route for it. This way the default route would have a hole for = the host routes of the MANET. > - Any network that attaches to the Internet these days needs > to have various policy knobs. Do you suggest that we simply > punt? Do we make a normative reference for some other > protocol that the IAR (or "Internet Gateway", or ...) > MUST implement? > > > Manet gateways are not an issue specific to reactive protocols. > Any such specification ought to apply to both reactive and > proactive protocols (such as discussed in the document I > submitted earlier for discussion). Did you have any comments > about that? I would expect every routing protocol to be able to deliver all kinds of = prefixes through its network, including the 0.0.0.0/0 and the ::/0 prefix= =2E As long as the prefixes do not overlap this is also non-problematic for=20 reactive routing protocols. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010309050205070508030206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTEwNzEwMDZaMCMGCSqGSIb3DQEJBDEWBBS3nXAXIVNxBtMs37YViHJ4D79SszBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAgvVYMEji4Hk870es7kccko2mdF2ef+wzJRL4sWQ4qB53 DUQZFHmjPifu5mE2okrkxi0fZvNs9W1HhcoRsdT28bjhc6Ep1hyP1PrfbTg+h4ADyeIIf1MA ZdVZ888wLGV8/1nnFOF5XqpOckqU7A8ISFXZ8SRWNwdvR9Znh7vxcdr6imsEHC8vLDAzhcBW gjBLcxZU9i5tDRnTElyMgyDQpwFWqxg7rvYflQUVtsw27GncfghkRiBRJsCoWNgBPWFBDflJ vyawiCYkCRxBwFRSagJQoK0bnZ+ZTCkB6vIuwHR0LTvIGRTLY8Cg08NvPSyvW1t5t+h+YG8/ ff9doneuBgAAAAAAAA== --------------ms010309050205070508030206-- From ulrich@herberg.name Thu Jan 10 23:25:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4461421F8AA3 for ; Thu, 10 Jan 2013 23:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJbh3FlvbF8z for ; Thu, 10 Jan 2013 23:25:38 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id CEAE621F8838 for ; Thu, 10 Jan 2013 23:25:38 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id hz1so856385pad.26 for ; Thu, 10 Jan 2013 23:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=3RAcuZQcWzJHcTuHs1BquLpYftC3zdA3rfuwOzmVbwI=; b=an1aW0E7za2O9NW6f1QZw28DRmZCVKNQiOupoDSmt8FCcaRM8+zmb0O/HLWETQNq3N jTY0DlMVZBmUuWgbU4l+Npx936U1An5P2tqwh4SgC2ZKRQxDkGA3Aawozxd6i2pUj1BT 3ZZaw0pN82lxzdx/gZh2eNu4nUwcftbUrpAXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=3RAcuZQcWzJHcTuHs1BquLpYftC3zdA3rfuwOzmVbwI=; b=RIk7npMfdfy98WcXX7PmF/LfCz1KtvVUOnjXwk7hAmVh1RXDPZfxnqaOgb8ZvzYJ7g Ej0q+tPei4LYO5A42io1ZomXh9vN0Iuv6zon/hsXcwiy7mUjjapdqurQvVvlBEjc8aiM zKs2NBw0677G3FcGduiVqRINMPM80IB37mrTLHxFEALjFtvcu6j2v3/VpIPOd8zB5HEq Bc+Kd01WPh3f6IsDHM30igX8MJ/US8yvVMN2zahM+pmOIsosf6MePMAgsvjSt4uffGeM 0jf2PLGqOABeG14qhHMLCLgceWsal2FCpDqpuWf0fUZg7kYP+EHMMSc75voj5GG424SK BCdg== X-Received: by 10.68.219.67 with SMTP id pm3mr228124378pbc.150.1357889138439; Thu, 10 Jan 2013 23:25:38 -0800 (PST) Received: from [10.0.1.12] (c-98-234-221-160.hsd1.ca.comcast.net. [98.234.221.160]) by mx.google.com with ESMTPS id d8sm2594741pax.23.2013.01.10.23.25.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 23:25:37 -0800 (PST) References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: <50EFB929.3000901@fkie.fraunhofer.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Thu, 10 Jan 2013 23:25:35 -0800 To: Henning Rogge X-Gm-Message-State: ALoCoQkbZFRvmejI63K0v8vOABC1mRLVBjvqupfoseSD+T+qUwrp7/ylgcvaSW/RFtJDms9NeB/H Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:25:40 -0000 I agree with Henning. A protocol using RFC5444 should not mandate a certain o= rder or a split into address blocks for the reasons Henning mentioned. The R= FC5444 parser/generator can be independent of the protocol that uses it (in m= y LOADng code that's the case), and used by several protocol implementations= and extensions concurrently. The protocols and extensions may not necessari= ly have the information about positions or split into address blocks. In LOADng, no such knowledge is required. Regards Ulrich On Jan 10, 2013, at 23:03, Henning Rogge w= rote: > On 01/10/2013 08:42 AM, Charles E. Perkins wrote: >> Hello Henning, >>=20 >> I'll put the issue on the Issue Tracker tomorrow. >>=20 >> However, there have been many protocols using positional information >> for lists (of addresses, etc) without impairment of extensibility. >> This is especially true when extensions go at the end. Do you have >> any particular example in mind where RFC 5444 somehow creates >> a problem with this? >=20 > With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because I c= an just add whatever I want to the protocol message, as long as I use new TL= Vs. >=20 > New addresses? No problem, regardless on the position. >=20 > New TLVs on existing addresses? No problem too. >=20 > Why use a pure TLV format if we put parts of the information into the orde= r and structure of the format and do NOT use TLVs for it? >=20 > The restriction of the order of addresses and the mandatory split into mul= tiple address blocks is also a problem for address compression. The order an= d split have a huge influence on the compression efficiency, demanding a spe= cific split/order will make AODVv2 messages larger in some cases. >=20 > Henning Rogge >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Peter.Hoefner@nicta.com.au Fri Jan 11 00:04:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABDC21F8A3F for ; Fri, 11 Jan 2013 00:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv5XtO3bmIVH for ; Fri, 11 Jan 2013 00:04:25 -0800 (PST) Received: from atp-es2.it.nicta.com.au (atp-es2.it.nicta.com.au [203.143.174.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1981A21F89C0 for ; Fri, 11 Jan 2013 00:04:25 -0800 (PST) Received: from atp-exchmbx1.it.nicta.com.au ([221.199.216.119] helo=atp-exchmbx1.in.nicta.com.au) by atp-es2.it.nicta.com.au with esmtp (Exim 4.72) (envelope-from ) id 1TtZb9-0007rX-CL; Fri, 11 Jan 2013 19:04:19 +1100 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx1.in.nicta.com.au (221.199.216.119) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 11 Jan 2013 19:04:18 +1100 Received: from callisto.dynhost.nicta.com.au (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 11 Jan 2013 19:04:17 +1100 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?Q?Peter_H=F6fner?= In-Reply-To: Date: Fri, 11 Jan 2013 19:04:17 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19546.005 X-TM-AS-Result: No--18.960100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-SA-Exim-Connect-IP: 221.199.216.119 X-SA-Exim-Mail-From: Peter.Hoefner@nicta.com.au X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000) X-SA-Exim-Scanned: Yes (on atp-es2.it.nicta.com.au) Cc: Rob van van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:04:26 -0000 Dear Abdussalam, > j node informs the the d node of such route otherwise how does the d > node know the route to the source s. You are right; in our example we didn't take into account the uRREP that j sends to d. Hence that example would not occur in the current version of AODVv2. In fact, $d$ would send a RREP via $j$. We have another example however where no RREP by an intermediate node is involved. It is presented at http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN2.pdf In that example, node D incrementing its own sequence number leads to a sub-optimal route to D by A. Naturally, sub-optimal route can occur all the time, but this is an example where we are worse off as a direct consequence of D incrementing its own sequence number when issuing a RREP. Does one of you know of an example where the destination incrementing its own sequence number (other than a RREQ induced increment) has any advantages? If so, one could try to analyse which problem is more prevalent, and hence which incrementation strategy is best. Here, with a "RREQ induced increment" we mean that if the RREQ lists a destination sequence number of n, indicating that n might be the latest one that stopped working for the source of the request, then the destination must increment its own sequence number to at least n+1. Cheers, Peter, Rob, Marius and Wee Lum ________________________________ The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments. From Peter.Hoefner@nicta.com.au Fri Jan 11 00:10:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C1821F8AB8 for ; Fri, 11 Jan 2013 00:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.709 X-Spam-Level: X-Spam-Status: No, score=-3.709 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XRnecylgi0V for ; Fri, 11 Jan 2013 00:10:47 -0800 (PST) Received: from ajax.nicta.com.au (ajax.nicta.com.au [221.199.217.11]) by ietfa.amsl.com (Postfix) with ESMTP id A113621F8A54 for ; Fri, 11 Jan 2013 00:10:47 -0800 (PST) Received: from atp-exchmbx2.it.nicta.com.au ([221.199.216.124] helo=atp-exchmbx1.in.nicta.com.au) by ajax.nicta.com.au with esmtp (Exim 4.72) (envelope-from ) id 1TtZhK-00086V-B9; Fri, 11 Jan 2013 19:10:46 +1100 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx2.in.nicta.com.au (221.199.216.124) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 11 Jan 2013 19:10:35 +1100 Received: from callisto.dynhost.nicta.com.au (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 11 Jan 2013 19:10:35 +1100 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?Q?Peter_H=F6fner?= In-Reply-To: <50EF0186.5020506@computer.org> Date: Fri, 11 Jan 2013 19:10:29 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <93A6223B-D3E0-4BEA-AF14-46413666737F@nicta.com.au> References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> <50EF0186.5020506@computer.org> To: Charles E.Perkins X-Mailer: Apple Mail (2.1283) X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19546.005 X-TM-AS-Result: No--9.626300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-SA-Exim-Connect-IP: 221.199.216.124 X-SA-Exim-Mail-From: Peter.Hoefner@nicta.com.au X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on ajax.nicta.com.au) Cc: Rob van van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:10:48 -0000 Hi Charlie, > Yes, it is possible to design RREP so that incrementing sequence > numbers is not always required. And, in fact, that was done in earlier > versions of DYMO. But I was not 100% certain that the design was > always an improvement, and it is really important to guarantee that > stale RREPs cannot cause loops. Our team develops mathematical techniques to formally analyse protocols; by this we can for example show the loop-freedom of protocols. We have already applied these techniques to several variants of the AODV protocol. When the AODVv2 draft is sufficiently stable, we might apply those techniques to the proposed protocol, so that we can in fact guarantee that stale RREPs cannot cause loops. This task does take some time, as it involves translating the protocol specification into a formal (unambiguous) specification language. > I am certainly open to improving the design of the sequence number > incrementation, and if you have a proposal please do share it with > the mailing list. If I were to make a proposal along these lines, I > would specify that the AODVv2 router generating the RREP SHOULD > NOT increment its sequence number unless either (i) its route table > has been updated with new destinations or metrics, or (ii) its > neighborhood has changed. Even that relatively loose constraint > could probably be relaxed further with additional record-keeping. Is it possible to sketch an example where restrictions (i) and (ii) are needed? This may help us working out a proposal on this point. Regards, Peter, Rob, Marius and Wee Lum ________________________________ The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments. From Peter.Hoefner@nicta.com.au Fri Jan 11 00:20:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35FE21F88D6 for ; Fri, 11 Jan 2013 00:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.239 X-Spam-Level: X-Spam-Status: No, score=-4.239 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni+t+lOU9qQl for ; Fri, 11 Jan 2013 00:20:41 -0800 (PST) Received: from atp-es2.it.nicta.com.au (atp-es2.it.nicta.com.au [203.143.174.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9626F21F8873 for ; Fri, 11 Jan 2013 00:20:40 -0800 (PST) Received: from atp-exchmbx1.it.nicta.com.au ([221.199.216.119] helo=atp-exchmbx1.in.nicta.com.au) by atp-es2.it.nicta.com.au with esmtp (Exim 4.72) (envelope-from ) id 1TtZqv-0007vl-HT; Fri, 11 Jan 2013 19:20:37 +1100 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx1.in.nicta.com.au (221.199.216.119) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 11 Jan 2013 19:20:36 +1100 Received: from callisto.dynhost.nicta.com.au (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 11 Jan 2013 19:20:35 +1100 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: =?iso-8859-1?Q?Peter_H=F6fner?= In-Reply-To: <7CB233D07722374DB3A5C088E1E8088B363FFFBE@e2010dag5.corp.ad.parc.com> Date: Fri, 11 Jan 2013 19:20:35 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <97B2731D-9C52-48DC-B461-6F5869C5EE02@nicta.com.au> References: <7CB233D07722374DB3A5C088E1E8088B363FFFBE@e2010dag5.corp.ad.parc.com> To: X-Mailer: Apple Mail (2.1283) X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19546.005 X-TM-AS-Result: No--16.919200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-SA-Exim-Connect-IP: 221.199.216.119 X-SA-Exim-Mail-From: Peter.Hoefner@nicta.com.au X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000) X-SA-Exim-Scanned: Yes (on atp-es2.it.nicta.com.au) Cc: Rob van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:20:42 -0000 Dear Marc, > In your diagram (c), node j does not increment its sequence number for d. > Intermediate RREP (iRREP) follow draft-perkins-irrep, not > draft-ietf-manet-dymo. It would be a bad thing for a node to have an > active route with a sequence number higher than the destination's own > seqnum. All active paths must be well-ordered according to 5.2.1. That's right, in our diagram (c), node j does not increment its sequence number for d when generating an iRREP: it was 2 and remains 2. We believe this follows the specification. In our diagram (c) node j updates its own sequence number from 2 to 3, when issuing the iRREP. We do not know if it is the intention of AODVv2 that this happens or not, but it makes no difference in our example. > Also, node j, according to draft-perkins-irrep, should send a uRREP to d > in addition to the iRREP to s. This would build a shortest-path d->j->s > reverse path that would not be overridden by the s->i->#->d rreq. One > would end up with an asymmetric route. Thanks for pointing out. We therefore made a different example (see our previous posting) that doesn't involve iRREPs. > ... As per your example, the destination only increases its > sequence number if the RREQ carried the current sequence number, so in > your case d would not increment because the RREQ along the s->i->#->d pat= h > carried seqnum 1 and d was was seqnum 2. Therefore, the RREPs at s would > both be seqnum 2 and s would use the shorter path. You are right; we agree with you that d should not increment its sequence n= umber in this situation. However, the current draft of AODVv2 (as we understand it) = does increment the sequence number of d. Cheers, Peter, Rob, Marius and Wee Lum ________________________________ The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments. From abdussalambaryun@gmail.com Fri Jan 11 02:24:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FFF21F87C4 for ; Fri, 11 Jan 2013 02:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4Jt4VnPP8Y9 for ; Fri, 11 Jan 2013 02:24:02 -0800 (PST) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id BC9CE21F8763 for ; Fri, 11 Jan 2013 02:24:01 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id fy7so1255823vcb.6 for ; Fri, 11 Jan 2013 02:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1s3t7U1Yv53sQMyISBcm931SBQiOEd1LS1lHiwFPF+Q=; b=NMpGYiI1nuYoiD93rGm5ct69uADvqFV6ZgVZcuiRKhdm5yYJdZCOSQJ9+IY9ibdNZ5 9bK+t1BaF1l8QpWdUs/z76oqg1i0Ug7MAJ8dr+xFkfX9mLnBEO+Q32VLhgJSiMaY5UE5 H/pTMo/lEpI08o3dUFFQkZb0hwF4bA9OyG+oGsO+e7tK6l0KhMuFK2w4dD7wg0TRCRgX 6NcqfTg0e26/b9nafgM8qrdCRtd6GMG6PXVIT45ZYvQUmK40MsIx01huZOZEJEoT525s v/68nY9KZj+0zvzrGDawvyaR59yBQtHu6mHdgRqahHlhQkBdt7pS621wyNujt+RANsg+ 6pUQ== MIME-Version: 1.0 Received: by 10.52.21.179 with SMTP id w19mr82270836vde.55.1357899841057; Fri, 11 Jan 2013 02:24:01 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 02:24:00 -0800 (PST) In-Reply-To: References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> Date: Fri, 11 Jan 2013 11:24:00 +0100 Message-ID: From: Abdussalam Baryun To: =?ISO-8859-1?Q?Peter_H=F6fner?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob van van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:24:03 -0000 Hi Peter, The new example now suggests topology change which always happens in MANET but don't know why you broadcast twice from A, if A sends a RREQ then if a new topology comes it will not send again. Only if the neighbors change is before the sending of intermediate nodes. if I mis-understood please advise, AB On 1/11/13, Peter H=F6fner wrote: > Dear Abdussalam, > >> j node informs the the d node of such route otherwise how does the d >> node know the route to the source s. > > You are right; in our example we didn't take into account the uRREP > that j sends to d. Hence that example would not occur in the current > version of AODVv2. In fact, $d$ would send a RREP via $j$. > > We have another example however where no RREP by an intermediate > node is involved. It is presented at > http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN2.pdf > > In that example, node D incrementing its own sequence number leads to > a sub-optimal route to D by A. Naturally, sub-optimal route can occur > all the time, but this is an example where we are worse off as a direct > consequence of D incrementing its own sequence number when issuing a RREP= . > > Does one of you know of an example where the destination incrementing > its own sequence number (other than a RREQ induced increment) has any > advantages? If so, one could try to analyse which problem is more > prevalent, and hence which incrementation strategy is best. > > Here, with a "RREQ induced increment" we mean that if the RREQ lists a > destination sequence number of n, indicating that n might be the latest > one that stopped working for the source of the request, then the > destination must increment its own sequence number to at least n+1. > > Cheers, > Peter, Rob, Marius and Wee Lum > > ________________________________ > > The information in this e-mail may be confidential and subject to legal > professional privilege and/or copyright. National ICT Australia Limited > accepts no liability for any damage caused by this email or its > attachments. > From abdussalambaryun@gmail.com Fri Jan 11 02:42:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245DA21F87E1 for ; Fri, 11 Jan 2013 02:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT5QR0cHUW9U for ; Fri, 11 Jan 2013 02:42:43 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5136A21F8717 for ; Fri, 11 Jan 2013 02:42:43 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so1270613vbb.21 for ; Fri, 11 Jan 2013 02:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4rPJlgbXkWim7kJegAP6xKIis0TumZWGPu/qtVYFQbA=; b=BIYa1e5y8axPUdGFZLJCMLAxXxWLxwAz6FKm52+20TiryEwjzI6ve6jdI0ILXrq3yP xwXB1rkszWG5bEDGWdipOlleXaTbCC9dGGWsYjZddxEVLIinjU2zCme8ZZVLI2lRcIpn /VG0PdtJ4A2TN1LDj/ZA0smbXZDfE+kxn2fDzrsukZemdp1vu3PAS8A3/PjYIlyABmj5 IxcjWEJAj6xxsmfDt+E+4gO8PXyWScdUPZewzW7CLIzv3K6LMdubCxh7LHeFzAxIVDrH SpFW1wSiHEwZvWL1jWde49WWtRMz/xw48GxvsF7n4OP+HBrEEEyi9mZmi2NDn8oV1tos oThQ== MIME-Version: 1.0 Received: by 10.220.247.136 with SMTP id mc8mr15300655vcb.44.1357900962683; Fri, 11 Jan 2013 02:42:42 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 02:42:42 -0800 (PST) In-Reply-To: <97B2731D-9C52-48DC-B461-6F5869C5EE02@nicta.com.au> References: <7CB233D07722374DB3A5C088E1E8088B363FFFBE@e2010dag5.corp.ad.parc.com> <97B2731D-9C52-48DC-B461-6F5869C5EE02@nicta.com.au> Date: Fri, 11 Jan 2013 11:42:42 +0100 Message-ID: From: Abdussalam Baryun To: =?ISO-8859-1?Q?Peter_H=F6fner?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Wee Lum Tan , manet@ietf.org, Marc.Mosko@parc.com, Rob van Glabbeek Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:42:45 -0000 >> ... As per your example, the destination only increases its >> sequence number if the RREQ carried the current sequence number, so in >> your case d would not increment because the RREQ along the s->i->#->d >> path >> carried seqnum 1 and d was was seqnum 2. Therefore, the RREPs at s would >> both be seqnum 2 and s would use the shorter path. > > You are right; we agree with you that d should not increment its sequence > number in > this situation. However, the current draft of AODVv2 (as we understand it) > does > increment the sequence number of d. The current draft does not increment SN twice when it receives two similar new RREQ. However, there may rare occur possibility of non-optimal in theory, but may be it is not non-optimal in practice, because the network topology is dynamic so you never know what will be the next topology. Therefore, under MANET the current draft AODVv2 gets to the optimal routes more frequent. AB From abdussalambaryun@gmail.com Fri Jan 11 02:45:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50021F8884 for ; Fri, 11 Jan 2013 02:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY5xvHuzWvGl for ; Fri, 11 Jan 2013 02:45:47 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id C405F21F87E1 for ; Fri, 11 Jan 2013 02:45:46 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so1278182vba.41 for ; Fri, 11 Jan 2013 02:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RqRQ4JQtF2uyODI1lfVwyhlR8ZweZ7/c3fGlK/tRv8o=; b=F1AqFA4ya1iUpY3kZc/luqm4h/oDSlumv/eJpclr0VsgNphfShvTWENPJMIBsjTJaq BpMpyZ7NXZmyU8ri5qcP9Hat6vms8VBfVa35ovTaPLCiNL5IEpSfV77PIuJU0xEv9yP/ WEILia0dg0SZIhPBE+DkAKQF15nBu9RXkTgQiYWYS7faF9zNGeSWiplv1VO/wZxJULNn mfxEoVvN7tBu6qCP1gGC2MAmVWdNGbsVnFyWZcTN9zLzS5ZBmroZOcEvceP2eW+IOQ08 nzQa88UrE/8ht07qFLrptaedyVvNhfJj07g1ZJOEMGO7fzqK2Q/QZTdaRFekg+0V1T6G o62A== MIME-Version: 1.0 Received: by 10.52.76.73 with SMTP id i9mr81023578vdw.25.1357901146135; Fri, 11 Jan 2013 02:45:46 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 02:45:46 -0800 (PST) In-Reply-To: <50EF6C81.6080604@computer.org> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EF6C81.6080604@computer.org> Date: Fri, 11 Jan 2013 11:45:46 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:45:47 -0000 Thanks Charlie, I missed that below message on 10 Dec 2012, http://www.ietf.org/mail-archive/web/manet/current/msg14394.html AB On 1/11/13, Charles E. Perkins wrote: > > Hello Abdussalam, > > On 1/10/2013 4:26 PM, Abdussalam Baryun wrote: >> (such as discussed in the document I >> submitted earlier for discussion). Did you have any comments >> about that? >> Which document you refer to? please give me name and date, > > Here is the information, which I sent out to the [manet] mailing list > on Dec. 10... > >> we had quite a lot of discussion about >> the gateway possibilities several years ago. Here's an old draft (that >> does work) from Ryuji: >> http://tools.ietf.org/id/draft-wakikawa-manet-globalv6-05.txt > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Fri Jan 11 07:23:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF321F8949 for ; Fri, 11 Jan 2013 07:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT4v783We94p for ; Fri, 11 Jan 2013 07:23:28 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 87B7A21F87A6 for ; Fri, 11 Jan 2013 07:23:27 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id m8so1520857vcd.22 for ; Fri, 11 Jan 2013 07:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2T1VbVGSvx+dGQ+/2M7xPQIEm2Oz7EQ1GWWZkaOEpCA=; b=xlQfnbka/TpFMFRBbYzlo+Zn30NLJg6N5J7MmvoyzwSJJ6Stp9kQoVnHjKrF9dL6nT ciUdpjK653YtlXtcRmqTw9Nw16/1cvar/QAh8/zVSjW9ejfaKxSgENjU1IGWUhOKJBYZ KE3Pozxgu4tlejshBddPDP9Uu7GANhFI+pP6vO0yGSITJ0cI2NPakCwh5nh93avm/dwU A/IBH1kxULf/4YWUn5Ahu60mG9hqqhreRVL4h4RgFIZj2fzKblVBUYaHrE1dzbXlsnNV TkSO27tkJ3W7BsBksXgp53L9mXruoI6XZ/gNrQXXobrVWCj5sq5NRwyO0vsH2mLL4ZJ+ kLrg== MIME-Version: 1.0 Received: by 10.220.8.18 with SMTP id f18mr92325255vcf.14.1357917806958; Fri, 11 Jan 2013 07:23:26 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 07:23:26 -0800 (PST) In-Reply-To: <50EFB929.3000901@fkie.fraunhofer.de> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> Date: Fri, 11 Jan 2013 15:23:26 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=bcaec54ee3e284972304d304e01c Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:23:29 -0000 --bcaec54ee3e284972304d304e01c Content-Type: text/plain; charset=ISO-8859-1 > > With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because I > can just add whatever I want to the protocol message, as long as I use new > TLVs. > > Yes that is an advantage of LOADng, but is the extend issue necessary for any 5444 message or protocol, > New addresses? No problem, regardless on the position. > > New TLVs on existing addresses? No problem too. > > Why use a pure TLV format if we put parts of the information into the > order and structure of the format and do NOT use TLVs for it? > > The restriction of the order of addresses and the mandatory split into > multiple address blocks is also a problem for address compression. The > order and split have a huge influence on the compression efficiency, > demanding a specific split/order will make AODVv2 messages larger in some > cases. > > I know that this issue of 5444 order/filling was not specified by the MANET WG yet, so do you think we SHOULD specify it, if yes, we need someone to write the ID. I remember this discussion was raised in DLEP messages as well, AB --bcaec54ee3e284972304d304e01c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
With NHDP, OLSRv2 and LOADng its trivial to extend the pr= otocol because I can just add whatever I want to the protocol message, as l= ong as I use new TLVs.

Yes that is an advantage of LOADng, but is the extend issue necessary = for any 5444 message or protocol,
=A0
New addresses? No problem, regardless on the position.
New TLVs on existing addresses? No problem too.

Why use a pure = TLV format if we put parts of the information into the order and structure = of the format and do NOT use TLVs for it?

The restriction of the order of addresses and the mandatory split into = multiple address blocks is also a problem for address compression. The orde= r and split have a huge influence on the compression efficiency, demanding = a specific split/order will make AODVv2 messages larger in some cases.
=A0
I know that this issue of 5444 order/filling was not specified by the = MANET WG yet, so do you think we SHOULD specify it, if yes, we need someone= to write the ID.=A0I remember this discussion was raised in DLEP messages= =A0as well,
=A0
AB
--bcaec54ee3e284972304d304e01c-- From hrogge@googlemail.com Fri Jan 11 08:27:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABF621F8319 for ; Fri, 11 Jan 2013 08:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSV2iQbxlC1p for ; Fri, 11 Jan 2013 08:27:18 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBC521F86EA for ; Fri, 11 Jan 2013 08:27:18 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so1975673lab.1 for ; Fri, 11 Jan 2013 08:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BCtT3dk5Ex0KGgO7xa/VF1uNge/JvGLVhQJQzl7DjfE=; b=PjgxW4ih6pwVRrwtCjdowe/ippa27qBhdnShboYavPmXd3inEhaj1Z0A9b+jJzujhv 99YMHCxzOzqmWgPRQyfkKlyIylJd9plvIujihVyF7UlFjVv8OhAxj9N51hr94/GlXGbE d72Apw2c3p1Ocip1UVO0CSm+2oWHdgaQx7yIb73LxgKlKlIQVM9w7MVnt9sDnHjtTWdi Cs4CEvOHARHDucb5fZsmp9O0tWC/h4z6Vi9N/6xmaZkp6QXpYVY73V7I6rs9NY0WvMtt yyka1/QLv4TLoxcpoh5TQWleCJ7Ftm6M6rKM4DlvsxJIUe4ibQsH0qNmboQlgrsrm6Je 7UrA== Received: by 10.152.113.165 with SMTP id iz5mr18192717lab.50.1357921637205; Fri, 11 Jan 2013 08:27:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Fri, 11 Jan 2013 08:26:57 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> From: Henning Rogge Date: Fri, 11 Jan 2013 17:26:57 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:27:19 -0000 On Fri, Jan 11, 2013 at 4:23 PM, Abdussalam Baryun wrote: >> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because I >> can just add whatever I want to the protocol message, as long as I use new >> TLVs. >> > Yes that is an advantage of LOADng, but is the extend issue necessary for > any 5444 message or protocol, If not we are wasting a lot of the capabilities of a TLV-based format. In addition to this the artificial split-up into multiple Address Blocks will make address compression much harder... which wastes bytes to be transferred over the MANET. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Fri Jan 11 08:50:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0C621F8A50 for ; Fri, 11 Jan 2013 08:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmkCsT+sIfib for ; Fri, 11 Jan 2013 08:50:11 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 695E321F8A3F for ; Fri, 11 Jan 2013 08:50:09 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 79CA4558FB0 for ; Fri, 11 Jan 2013 08:50:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 10C801CCA51; Fri, 11 Jan 2013 08:50:06 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id ED9321CCA09; Fri, 11 Jan 2013 08:50:03 -0800 (PST) References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Fri, 11 Jan 2013 17:50:03 +0100 To: Ulrich Herberg Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:50:16 -0000 In complete agreement with Ulrich here.=20 Associating semantics to ordering of TLVs or addresses in 5444 removes the a= bility for generic parsers and generators. That would be a very unfortunate d= esign, given that 5444 was designed exactly to be generic. Thomas Sent from my iPad On 11 janv. 2013, at 08:25, Ulrich Herberg wrote: > I agree with Henning. A protocol using RFC5444 should not mandate a certai= n order or a split into address blocks for the reasons Henning mentioned. Th= e RFC5444 parser/generator can be independent of the protocol that uses it (= in my LOADng code that's the case), and used by several protocol implementat= ions and extensions concurrently. The protocols and extensions may not neces= sarily have the information about positions or split into address blocks. >=20 > In LOADng, no such knowledge is required. >=20 > Regards > Ulrich >=20 > On Jan 10, 2013, at 23:03, Henning Rogge wrote: >=20 >> On 01/10/2013 08:42 AM, Charles E. Perkins wrote: >>> Hello Henning, >>>=20 >>> I'll put the issue on the Issue Tracker tomorrow. >>>=20 >>> However, there have been many protocols using positional information >>> for lists (of addresses, etc) without impairment of extensibility. >>> This is especially true when extensions go at the end. Do you have >>> any particular example in mind where RFC 5444 somehow creates >>> a problem with this? >>=20 >> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because I= can just add whatever I want to the protocol message, as long as I use new T= LVs. >>=20 >> New addresses? No problem, regardless on the position. >>=20 >> New TLVs on existing addresses? No problem too. >>=20 >> Why use a pure TLV format if we put parts of the information into the ord= er and structure of the format and do NOT use TLVs for it? >>=20 >> The restriction of the order of addresses and the mandatory split into mu= ltiple address blocks is also a problem for address compression. The order a= nd split have a huge influence on the compression efficiency, demanding a sp= ecific split/order will make AODVv2 messages larger in some cases. >>=20 >> Henning Rogge >>=20 >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jan 11 09:34:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8C521F884A for ; Fri, 11 Jan 2013 09:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLzft9sn-0L1 for ; Fri, 11 Jan 2013 09:34:25 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9995621F8838 for ; Fri, 11 Jan 2013 09:34:24 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id l6so1694100vcl.9 for ; Fri, 11 Jan 2013 09:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MELRocoP0koVCd8RNXdWh3nMhIPpVnizGA8akq6t698=; b=tgROHAalAbAZtJQ+EZjnch05lKkijdgrG62y08RWuOn8hciLLgXpQaaghhNEHfBIwG TGdv3hpO+2k7XTv/m6V3crwLZNMaXyKfUpOL88CyVyxG2IK0YmzcLlC1xbDbhc2sX5rB UT+hOdKY90OdxLYxCXiqjz5Uqe1fAofqn+HkEyX8iJbyLMm1xc84N/HWDUUi/G5dkhm/ wOXdkjj6UIgd2PQK3bOsus9Wb7KsVvQgjDzVcmhE3HHLiaQ92m+Q0Gb6Eaz94Eb5+Yl3 ZpMCLUVj+fBj3M25ME0HRW0xgSZQRFUxZFSnfrCEZZvkNF/wbbh/u3KFc0IMf/DeChRY 7wjQ== MIME-Version: 1.0 Received: by 10.52.27.50 with SMTP id q18mr83438019vdg.20.1357925663633; Fri, 11 Jan 2013 09:34:23 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 09:34:23 -0800 (PST) In-Reply-To: <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> Date: Fri, 11 Jan 2013 18:34:23 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:34:29 -0000 Hi Thomas, I like RFC5444 that it is named general format so that any protocol uses it the way best for the protocol's functions. This is why I see advantages also in AODVv2 use of the 5444, and also the DLEP use of 5444. However, still the WG did not specify how to use the 5444 messaging in a general protocol. I remember this was discussed between you and Teco in one meeting, regarding security issues of RFC5444 and that the co-chair asked if one is welling to specify the 5444 format filling methods for the WG. AB On 1/11/13, Thomas Heide Clausen wrote: > In complete agreement with Ulrich here. > > Associating semantics to ordering of TLVs or addresses in 5444 removes th= e > ability for generic parsers and generators. That would be a very unfortun= ate > design, given that 5444 was designed exactly to be generic. > > Thomas > > Sent from my iPad > > On 11 janv. 2013, at 08:25, Ulrich Herberg wrote: > >> I agree with Henning. A protocol using RFC5444 should not mandate a >> certain order or a split into address blocks for the reasons Henning >> mentioned. The RFC5444 parser/generator can be independent of the protoc= ol >> that uses it (in my LOADng code that's the case), and used by several >> protocol implementations and extensions concurrently. The protocols and >> extensions may not necessarily have the information about positions or >> split into address blocks. >> >> In LOADng, no such knowledge is required. >> >> Regards >> Ulrich >> >> On Jan 10, 2013, at 23:03, Henning Rogge >> wrote: >> >>> On 01/10/2013 08:42 AM, Charles E. Perkins wrote: >>>> Hello Henning, >>>> >>>> I'll put the issue on the Issue Tracker tomorrow. >>>> >>>> However, there have been many protocols using positional information >>>> for lists (of addresses, etc) without impairment of extensibility. >>>> This is especially true when extensions go at the end. Do you have >>>> any particular example in mind where RFC 5444 somehow creates >>>> a problem with this? >>> >>> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because= I >>> can just add whatever I want to the protocol message, as long as I use >>> new TLVs. >>> >>> New addresses? No problem, regardless on the position. >>> >>> New TLVs on existing addresses? No problem too. >>> >>> Why use a pure TLV format if we put parts of the information into the >>> order and structure of the format and do NOT use TLVs for it? >>> >>> The restriction of the order of addresses and the mandatory split into >>> multiple address blocks is also a problem for address compression. The >>> order and split have a huge influence on the compression efficiency, >>> demanding a specific split/order will make AODVv2 messages larger in so= me >>> cases. >>> >>> Henning Rogge >>> >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Jan 11 09:38:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134D721F87B2 for ; Fri, 11 Jan 2013 09:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndzIs8URpMB8 for ; Fri, 11 Jan 2013 09:38:25 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9721F8797 for ; Fri, 11 Jan 2013 09:38:25 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id fo13so1676662vcb.35 for ; Fri, 11 Jan 2013 09:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eyrXHSw1YihLM4c5quvMQld7C5oQJtaUHRqNTKxpJKM=; b=MwBWrEcb5j7iBVuEcGABeDGG0qjTPNCcAMLDHTgAXuwNQ3jKWYYmE4p1fmjYUErv2G PNA2yYeOwTaeWC1YYVfvcrjA3EpP7//eCp1YV+E4MYRgCjvN4DOOs1UZW0rTUleIaXBP QEx3hvwx7/djD3pcZnHErUwnE1qlXXRfx4ly2XQhC+StzuVMvJzgov79PSb0l/gh27+8 x8WlecznntCmELV4uyTrykLBAgLxTe8TLtEPiua3/Nh4Vdlw4NZ0t3MhpMlF4tGRVg1M DnLq2uVLq33b5Xs65fnPIpuPxvkHEBhJ28z3Y/o54gprOVkAIhcR0CBZ/XRwcupA6xy8 bFVg== MIME-Version: 1.0 Received: by 10.58.198.135 with SMTP id jc7mr95894596vec.51.1357925904875; Fri, 11 Jan 2013 09:38:24 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 09:38:24 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> Date: Fri, 11 Jan 2013 18:38:24 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:38:28 -0000 Hi Henning, There are always reasons for the way AODVv2 was done, however, I think the authors of AODVv2 will explain better why such way, for me I only checked the protocol functions, but interested to know more and if it can be improved, thanks, AB On 1/11/13, Henning Rogge wrote: > On Fri, Jan 11, 2013 at 4:23 PM, Abdussalam Baryun > wrote: >>> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because >>> I >>> can just add whatever I want to the protocol message, as long as I use >>> new >>> TLVs. >>> >> Yes that is an advantage of LOADng, but is the extend issue necessary for >> any 5444 message or protocol, > > If not we are wasting a lot of the capabilities of a TLV-based format. > In addition to this the artificial split-up into multiple Address > Blocks will make address compression much harder... which wastes bytes > to be transferred over the MANET. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From hrogge@googlemail.com Fri Jan 11 09:43:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244AC21F8919 for ; Fri, 11 Jan 2013 09:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVoY5CztUvsa for ; Fri, 11 Jan 2013 09:43:16 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id B03B821F886F for ; Fri, 11 Jan 2013 09:43:11 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id n10so1500988lbo.36 for ; Fri, 11 Jan 2013 09:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rwvvZdSdpe/bpGBiQMdsbvt+vCelQL+oUstc0pC/ZAA=; b=FjBcipQbobJkxxGQtXF9+JqoHHls8lLecgA1vbmPM2Dz2YlvxHruF4u4V+QLrTwkW5 zoeL0n2SMO2oFRrLF51bzcHxdbJ2rjie9VR6wcKoErkOwqyjTddwTCZP/LaaTX7sd8A9 DdFfvUsn1g4ha+FOA6/e4Wtlzo8Wf3TPvEZ9wBl+qBNV5dQeg7aJ2+RACmW7AtQJlpKk sTx2W65Xd7zszpmyE7PvXC8JKnHxKcrafyRn2g3h4k94ls31OoviYVqe9Yb3IIySj10P Le4GT95IS+D+nTXEw/WDl8gLmGMNrxuaWQ+MmWNHT3JaEup8WoYATyn+DWQg/PsvSq/9 9vGQ== Received: by 10.152.122.39 with SMTP id lp7mr73719342lab.0.1357926190572; Fri, 11 Jan 2013 09:43:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Fri, 11 Jan 2013 09:42:50 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> From: Henning Rogge Date: Fri, 11 Jan 2013 18:42:50 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:43:18 -0000 On Fri, Jan 11, 2013 at 6:38 PM, Abdussalam Baryun wrote: > Hi Henning, > > There are always reasons for the way AODVv2 was done, however, I think > the authors of AODVv2 will explain better why such way, for me I only > checked the protocol functions, but interested to know more and if it > can be improved, thanks, The only reason I can see (but do NOT agree upon) is that a full RFC5444 design is a little bit more difficult to parse. But the higher flexibility and the chance for a better compression should easily compensate for this. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From yi.jiazi@gmail.com Fri Jan 11 09:53:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B58921F86FD for ; Fri, 11 Jan 2013 09:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=-3.242, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCATQ9gMEDwa for ; Fri, 11 Jan 2013 09:53:07 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84B21F895F for ; Fri, 11 Jan 2013 09:53:01 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id dr1so32739wgb.5 for ; Fri, 11 Jan 2013 09:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=wjd1GyttqqNIM3elTlYL4D4Ob7TkIlVs4AmLuwxb1iM=; b=hDNws2bawh/4xRNlrNeQo3p3EZMvm96Q+lSu/v/EtM4mWRv2HF3/naPKDhP6BekN5h OEO33T5bQJxGrMKoOOSBe+qmM6xyUyKeVGwSxXVyv1qP8gTi5ThXWr3MuoFaejJ2q2M/ lnmgCJlaRH8FKx3iniBp2mo8gMuZVygzRyH+z8qjXexdYK+x7Catuher66HIKQztlLo5 3wWRagFG+dEjG9VGLeyWIIQtxf3HzbolEQJiKFWkIiGkQB2y0kwwWKPH+NWLD9J3Xfrr VQSoHIU4Ma7mhqj+SNaCOi7kM0V/pmGim2ZoDGo9bx5bdT95jpR6/pCtBywzAYETrAIV geZA== X-Received: by 10.194.123.105 with SMTP id lz9mr122893201wjb.43.1357926773474; Fri, 11 Jan 2013 09:52:53 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id hu8sm81192wib.6.2013.01.11.09.52.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 09:52:53 -0800 (PST) Sender: Jiazi YI From: Jiazi Yi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jan 2013 18:52:50 +0100 References: <20130111174808.7795.50479.idtracker@ietfa.amsl.com> To: "manet@ietf.org List" Message-Id: <79659D5C-6F72-4FE5-9F0A-FB8C564C9254@jiaziyi.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:53:14 -0000 Dear all,=20 We have released the -08 revision of LOADng. The main update is that a = new section named "Implementation Status" has been added.=20 This is based on the suggestions from draft-sheffer-running-code-01, = Improving "Rough Consensus" with Running Code ( = http://tools.ietf.org/html/draft-sheffer-running-code-01 ).=20 According to draft-sheffer-running-code-01: "there are many examples of Internet-Drafts containing protocol = specification that have gone through to publication as Proposed = Standard RFCs without implementation. Some of them may never get = implemented." and=20 "this (Implementation Status) will allow reviewers and working groups to = assign due consideration to documents that have the benefit of running = code and potentially reward the documented protocols by treating the = documents with implementations preferentially" In the new section, we described four implementations of LOADng, and we = will try to release more details in the future.=20 Comments are welcome.=20 best Jiazi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-clausen-lln-loadng-08.txt > Date: January 11, 2013 6:48:08 PM GMT+01:00 > To: jiazi@jiaziyi.com > Cc: axel@axelcdv.com, t.clausen@computer.org, charliep@computer.org, = ulrich@herberg.name, cedric-2.lavenu@edf.fr, = afshin.niktash@maxim-ic.com, yuichi.igarashi.hb@hitachi.com, = thierry.lys@erdfdistribution.fr, hiroki.satoh.yj@hitachi.com, = jdean@itd.nrl.navy.mil >=20 >=20 > A new version of I-D, draft-clausen-lln-loadng-08.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Filename: draft-clausen-lln-loadng > Revision: 08 > Title: The Lightweight On-demand Ad hoc = Distance-vector Routing Protocol - Next Generation (LOADng) > Creation date: 2013-01-11 > WG ID: Individual Submission > Number of pages: 69 > URL: = http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-08.txt > Status: = http://datatracker.ietf.org/doc/draft-clausen-lln-loadng > Htmlized: = http://tools.ietf.org/html/draft-clausen-lln-loadng-08 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-clausen-lln-loadng-08 >=20 > Abstract: > This document describes the Lightweight Ad hoc On-Demand - Next > Generation (LOADng) distance vector routing protocol, a reactive > routing protocol intended for use in Mobile Ad hoc NETworks = (MANETs). >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From abdussalambaryun@gmail.com Fri Jan 11 10:33:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1021F890D for ; Fri, 11 Jan 2013 10:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7xlRuQILxXl for ; Fri, 11 Jan 2013 10:33:13 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 09F9621F8903 for ; Fri, 11 Jan 2013 10:33:12 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id f13so1740613vcb.18 for ; Fri, 11 Jan 2013 10:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=575Mn3/VN6BV1+Q4EwCYr+Df9d1TazQbAzQnYA8gIAY=; b=Fh5umRkIXNLTl0T4UC6U/yBX5TomSIcvbDY+BtJysYWmmzV9ipmUwIaIF9pHSLdAl8 2vQMechSF+4v1QCtqSS4UM8I32T6TeDmdaEPCXj/d5LRQpWpwgfmGZ5OosBBldEqz7h1 ZaxbD5V+jM4ohIuq1SR5lK0ReYUiEECQbyrb+K6GtCMACGmbB2YEFT0ucslqJqYB6Ajv 49GwfpXyXPY7rHEgkZ3OTTZZjnFbaSIa0JhXJflMtab2zaWBwkzqkCEvB0m6FYUaBtF0 hngrWWtMIHZ5sayHpulwaA1e60h1rfthB4N82pKPn/PSdMzCRiddndi0bWvie+g5Nf8K E0Dg== MIME-Version: 1.0 Received: by 10.58.198.135 with SMTP id jc7mr96051622vec.51.1357929191923; Fri, 11 Jan 2013 10:33:11 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 10:33:11 -0800 (PST) In-Reply-To: <79659D5C-6F72-4FE5-9F0A-FB8C564C9254@jiaziyi.com> References: <20130111174808.7795.50479.idtracker@ietfa.amsl.com> <79659D5C-6F72-4FE5-9F0A-FB8C564C9254@jiaziyi.com> Date: Fri, 11 Jan 2013 19:33:11 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org List" Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 18:33:22 -0000 Hi Jiazi, Thanks, it is good to add this section, I have no objection as long it does not confuses doc aim, I prefer to separate implementation from standard, but maybe there is always other reasons I may not know. However, I like to learn about this thanks, AB On 1/11/13, Jiazi Yi wrote: > Dear all, > > We have released the -08 revision of LOADng. The main update is that a new > section named "Implementation Status" has been added. > > This is based on the suggestions from draft-sheffer-running-code-01, > Improving "Rough Consensus" with Running Code ( > http://tools.ietf.org/html/draft-sheffer-running-code-01 ). > According to draft-sheffer-running-code-01: > > "there are many examples of Internet-Drafts containing protocol > specification that have gone through to publication as Proposed Standard > RFCs without implementation. Some of them may never get implemented." > > and > > "this (Implementation Status) will allow reviewers and working groups to > assign due consideration to documents that have the benefit of running code > and potentially reward the documented protocols by treating the documents > with implementations preferentially" > > In the new section, we described four implementations of LOADng, and we will > try to release more details in the future. > > Comments are welcome. > > best > > Jiazi > > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-clausen-lln-loadng-08.txt >> Date: January 11, 2013 6:48:08 PM GMT+01:00 >> To: jiazi@jiaziyi.com >> Cc: axel@axelcdv.com, t.clausen@computer.org, charliep@computer.org, >> ulrich@herberg.name, cedric-2.lavenu@edf.fr, afshin.niktash@maxim-ic.com, >> yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, >> hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil >> >> >> A new version of I-D, draft-clausen-lln-loadng-08.txt >> has been successfully submitted by Jiazi Yi and posted to the >> IETF repository. >> >> Filename: draft-clausen-lln-loadng >> Revision: 08 >> Title: The Lightweight On-demand Ad hoc Distance-vector Routing Protocol >> - Next Generation (LOADng) >> Creation date: 2013-01-11 >> WG ID: Individual Submission >> Number of pages: 69 >> URL: >> http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-08.txt >> Status: http://datatracker.ietf.org/doc/draft-clausen-lln-loadng >> Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-08 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-08 >> >> Abstract: >> This document describes the Lightweight Ad hoc On-Demand - Next >> Generation (LOADng) distance vector routing protocol, a reactive >> routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). >> >> >> >> >> The IETF Secretariat >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Jan 11 10:42:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4F521F8A6F for ; Fri, 11 Jan 2013 10:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb+4ZEtbwL1b for ; Fri, 11 Jan 2013 10:42:13 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7634F21F89FD for ; Fri, 11 Jan 2013 10:42:12 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id gb30so1760071vcb.12 for ; Fri, 11 Jan 2013 10:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M/6xkIC8DTiyltRdk9t4w/93DZsWc58JFOASeAP8v24=; b=yeoOXMnKVmlxfNiOqU5wU4pDjMrO5gr9jQrO6D0NgwaHKyCGVivZ1ahXgTVXKJlK2U 1XIqCwVgncxUV02zbagCfhItWxccbGqXpvsqVhGu4gLgpPVbmw6QgfxVkCbGCUtjz62L NqKBwQ/jhb3IioFObYDUrabfP850i/2qg7JX079FCg8Ejek4ng+eYOS2FEcVtYWsTDpR lgSkphHDkuESbMfwcD6GxiY2XfMbSWmTC3DvOWOROByd+fQoAH1PPcluL50IB5JFtFRc +6EN2DoKT+DhUKW3MV/oVkXSD98Hf/mh2Q7+2JuuXj01tXL2JDJXW9Bim4Pwib7Sr1ZC 8CHw== MIME-Version: 1.0 Received: by 10.52.27.50 with SMTP id q18mr83605568vdg.20.1357929731776; Fri, 11 Jan 2013 10:42:11 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 11 Jan 2013 10:42:11 -0800 (PST) In-Reply-To: References: <20130111174808.7795.50479.idtracker@ietfa.amsl.com> <79659D5C-6F72-4FE5-9F0A-FB8C564C9254@jiaziyi.com> Date: Fri, 11 Jan 2013 19:42:11 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org List" Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 18:42:15 -0000 Hi Jiazi, ok, I got that wrong, you mean *informational section* about implementations in labs, that will be excellent. I actually asked questions many times about the LOADng implementation and no answer from the authors, and now this section have answered, after a long time of reminders. However, seems that the authors realized its importance after all, AB On 1/11/13, Abdussalam Baryun wrote: > Hi Jiazi, > > Thanks, it is good to add this section, I have no objection as long it > does not confuses doc aim, I prefer to separate implementation from > standard, but maybe there is always other reasons I may not know. > However, I like to learn about this thanks, > > AB > > On 1/11/13, Jiazi Yi wrote: >> Dear all, >> >> We have released the -08 revision of LOADng. The main update is that a >> new >> section named "Implementation Status" has been added. >> >> This is based on the suggestions from draft-sheffer-running-code-01, >> Improving "Rough Consensus" with Running Code ( >> http://tools.ietf.org/html/draft-sheffer-running-code-01 ). >> According to draft-sheffer-running-code-01: >> >> "there are many examples of Internet-Drafts containing protocol >> specification that have gone through to publication as Proposed Standard >> RFCs without implementation. Some of them may never get implemented." >> >> and >> >> "this (Implementation Status) will allow reviewers and working groups to >> assign due consideration to documents that have the benefit of running >> code >> and potentially reward the documented protocols by treating the documents >> with implementations preferentially" >> >> In the new section, we described four implementations of LOADng, and we >> will >> try to release more details in the future. >> >> Comments are welcome. >> >> best >> >> Jiazi >> >> >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-clausen-lln-loadng-08.txt >>> Date: January 11, 2013 6:48:08 PM GMT+01:00 >>> To: jiazi@jiaziyi.com >>> Cc: axel@axelcdv.com, t.clausen@computer.org, charliep@computer.org, >>> ulrich@herberg.name, cedric-2.lavenu@edf.fr, >>> afshin.niktash@maxim-ic.com, >>> yuichi.igarashi.hb@hitachi.com, thierry.lys@erdfdistribution.fr, >>> hiroki.satoh.yj@hitachi.com, jdean@itd.nrl.navy.mil >>> >>> >>> A new version of I-D, draft-clausen-lln-loadng-08.txt >>> has been successfully submitted by Jiazi Yi and posted to the >>> IETF repository. >>> >>> Filename: draft-clausen-lln-loadng >>> Revision: 08 >>> Title: The Lightweight On-demand Ad hoc Distance-vector Routing >>> Protocol >>> - Next Generation (LOADng) >>> Creation date: 2013-01-11 >>> WG ID: Individual Submission >>> Number of pages: 69 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-08.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-clausen-lln-loadng >>> Htmlized: http://tools.ietf.org/html/draft-clausen-lln-loadng-08 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-clausen-lln-loadng-08 >>> >>> Abstract: >>> This document describes the Lightweight Ad hoc On-Demand - Next >>> Generation (LOADng) distance vector routing protocol, a reactive >>> routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > From adrian@olddog.co.uk Sat Jan 12 09:21:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FA921F868F for ; Sat, 12 Jan 2013 09:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDc-70pznjfO for ; Sat, 12 Jan 2013 09:21:11 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3D21F852B for ; Sat, 12 Jan 2013 09:21:10 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0CHL9Hf019397 for ; Sat, 12 Jan 2013 17:21:09 GMT Received: from 950129200 (089144192042.atnat0001.highway.a1.net [89.144.192.42]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0CHL1GE019336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 12 Jan 2013 17:21:08 GMT From: "Adrian Farrel" To: Date: Sat, 12 Jan 2013 17:21:02 -0000 Message-ID: <007301cdf0e9$37622ec0$a6268c40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3w5si/qTpvNF0ZS3aJfmbPjWbI+w== Content-Language: en-gb Subject: [manet] Reactive protocol decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 17:21:12 -0000 Can I beg your indulgence a little while longer as I polish my email and sign it off with the chairs, Thanks, Adrian From abdussalambaryun@gmail.com Sat Jan 12 10:18:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587AE21F8506 for ; Sat, 12 Jan 2013 10:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmTKKYPAbvlV for ; Sat, 12 Jan 2013 10:18:22 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id ADBCA21F8750 for ; Sat, 12 Jan 2013 10:18:22 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so2375331vby.19 for ; Sat, 12 Jan 2013 10:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dIaBeMuvLLGOqqQoysim/p9we4GpZiQ6HXdaf4hOuWM=; b=pAXyRGEoHf0lXvuwVgZEa6EeBwb6NPAJO4V/cHKCYYlyWh0MM1SEuGo4cZp1eVVDI0 dX/DVEHq+hvAkJtjsKVFiqwbktJXrZ9D0aWoglJyo0gT0xDUcOVlsfrqRO71MPWbcsgG AMRgz2Ahu/zY3nUvZZjQK43rMTsmK7qJf/Rz7jUNQXj49F+RZSScD3Fn5IAv2YjJFYVw PnhVbx77Bk9pHgKyDv0L6082pDT7bAkuGWfX4I+II8IftmHJ6E+GdBn1yqhE8I12YAkj 86Vgjm8uGVNDLMZmMo3y6K8dNk1ZZzdMviUcV++eMbqATq7ay6HgBXxxXucfOrdzUuK7 Tegg== MIME-Version: 1.0 Received: by 10.220.149.69 with SMTP id s5mr97898171vcv.23.1358014701954; Sat, 12 Jan 2013 10:18:21 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sat, 12 Jan 2013 10:18:21 -0800 (PST) In-Reply-To: <007301cdf0e9$37622ec0$a6268c40$@olddog.co.uk> References: <007301cdf0e9$37622ec0$a6268c40$@olddog.co.uk> Date: Sat, 12 Jan 2013 18:18:21 +0000 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=f46d042fd898e8e81304d31b6f91 Cc: manet@ietf.org Subject: Re: [manet] Reactive protocol decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 18:18:23 -0000 --f46d042fd898e8e81304d31b6f91 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, I thank you very much for this information, at least I know there is a decision made, but for the longer time no problem, for myself I would be happy to know the decision even before end this month or the next meeting at most. Regards AB On Sat, Jan 12, 2013 at 5:21 PM, Adrian Farrel wrote: > Can I beg your indulgence a little while longer as I polish my email and > sign it > off with the chairs, > > Thanks, > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d042fd898e8e81304d31b6f91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
=A0
I thank you very much for this info= rmation,=A0at least I know there is a decision made, but for the longer tim= e no problem, for myself I would be happy=A0to know the decision even=A0bef= ore end this month or the next meeting at most.
=A0
Regards
AB

On Sat, Jan 12, 2013 at 5:21 PM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:
Can I beg your indulgence a little while longer as I polis= h my email and sign it
off with the chairs,

Thanks,
Adrian

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d042fd898e8e81304d31b6f91-- From shares@ndzh.com Sun Jan 13 21:03:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBDD21F8514 for ; Sun, 13 Jan 2013 21:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiB2blpsIE6Y for ; Sun, 13 Jan 2013 21:03:33 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E921F870E for ; Sun, 13 Jan 2013 21:03:32 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: Date: Mon, 14 Jan 2013 00:03:28 -0500 Message-ID: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CDF1EA.9532D430" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yEHykR0g2R59KSJCVPLNaxBO4sg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 05:03:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0006_01CDF1EA.9532D430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Technical issue 1: Sequence numbers DYMO-25 Text: An AODVv2 Sequence Number is an unsigned integer maintained by each AODVv2 router. This sequence number guarantees the temporal order of routing information to maintain loop-free routes. The value zero (0) is reserved to indicate that the SeqNum for a destination address is unknown. Question text: In a monotonically increasing sequence number you have three issues: 1 - unique sequence linkage to node/port/update(e.g. LSA) 2 - sequence number wrap 3 - when to sequence number increment. The delightful thread started a concrete discussion on sequence number incrementing at the RREPLY node. However, I have not notice on the recent thread the discussion of the other issues so I will start with questions about these issues. #1 - unique node - sequence number linkage >From the DYMO text, the sequence number is monotonically increases per node address. If you lose the node address-sequence number link, it appears that this linkage is broken. This true of any sending of sequence (RREQ, RREP). If you do not lose the unique linkage, then you must consider that an immediately previous sequence number in a RREQ or RREP is out of date. In the example in file non-opt_incSQN2.ppt, my question to Peter is if you know the packet comes for A and has an old sequence number in (f), you have the appropriate information (path 1: S-A-D, xmt node A, seq 1) and (path 2: s-A-I-D xmt A, seq 1). Q1: How is the unique node address selected? Did the WG group have a security/theoretical discussion on using the loopback IP address versus other addresses? (e.g. DOS on loopback addresses) If you can point to an archive discussion, I'm glad to go read it. I would expect that the sharp minds in this WG would have debated these points. [Please note I have tried to state this question to get at the theory behind any selection of unique node - sequence number linkage - rather than DYMO versus LOADng question. I'm glad to learn from DYMO or LOADng text, but I'm trying to see the theory]. #2 Sequence numbers always wrap and sequence number reuse depends on the time and/or wrap detection. Formats usually do not impose a particular wrap value. Common values are zero or all ones (-1) to aid quick identification of the wrap. It is not surprising therefore that: a) Loadng - uses a simple number format with -1 was wrap value INMU (in my understanding) wrap goes -2, 0 b) Dymo - uses a TLV format with 0 as both initial number and wrap. INMU - the wrap goes -1, 1 Sequence number time is usually 2* the wrap time so junk can clear from the network. Therefore the equation is: MAX_SEQ_LIFETIME = 2 * normal_wrap_time Distance vector routes may encounter route cycling (count to infinity in RIP, BGP MED harmful/BGP flapping) in certain topologies. Rapidly changing mobile topologies may cycle through topologies that do and do not cause this route fluctuation. The validity timer and max-sequence timer seems to be addressing this issue. Q2: Am I correct? The timers in DYMO-24 are: +------------------------------+-------------+ | Name | Value | +------------------------------+-------------+ | ACTIVE_INTERVAL | 5 second | | MAX_IDLETIME | 200 seconds | | MAX_SEQNUM_LIFETIME | 300 seconds | | ROUTE_RREQ_WAIT_TIME | 2 seconds | | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | | RREQ_HOLDDOWN_TIME | 10 seconds | --------------------------------------------- Here's my set of equations: Validity timer ::=max time before route declared invalid = ACTIVE_INTERNAL + MAX_IDLETIME - (Current_time-Routelast.used) Expired route ::= route expired, but sequence number cannot be used :: = valid_time < expired route < MAX_SEQNUM_TIME Q3: Can you correct these equations or add to them? Architecture questions: 1. How does MAX_SEQNUM_TIME interact with the real wrapping functions during fast node motion to slow node motion so that links come and go (per 2c of Gabblek, Hofner, Portman and Tan's diagram (non-opt_incSQN2.pdf) As a note to Gabblek et al. (2013), you may want to examine IEEE Sensor conference papers on this topic. 2. What conditions cause all nodes to engage in a sequence number wrap? For example, would fast mobility of nodes with fast link breakage cause these problems? 3. One important issue is the restart of things after power loss or reboot (likely from software errors). Does the node going down require that a sequence number to be maintained in NVRAM? 4. Is there a reason for the Address Block TLV route passed through to time out different that the originating node? If so, does (or does it not) impact the sequence number wrap. Thank you for aid in helping me come up to speed on your past discussion, and current thought. Sue Hares ------=_NextPart_000_0006_01CDF1EA.9532D430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Technical issue 1: Sequence numbers =

 

DYMO-25 Text: =

 

An AODVv2 = Sequence Number is an unsigned integer maintained by each AODVv2 = router.  This sequence number guarantees the temporal order of = routing information to maintain loop-free routes.  The value zero = (0) is reserved to indicate that the SeqNum for a destination address is = unknown.

 

Question text: =  

 

In a = monotonically increasing sequence number you have three = issues:

 

1 – unique = sequence linkage to node/port/update(e.g. LSA)

2 – = sequence number wrap

3 – when to = sequence number increment.

 

 

The delightful = thread started a concrete discussion on sequence number incrementing at = the RREPLY node. However, I have not notice on the recent thread the = discussion of the other issues so I will start with questions about = these issues.

 

 

#1 – unique = node - sequence number linkage

 

From the DYMO = text, the sequence number is monotonically increases per node address. = If you lose the node address-sequence number link, it appears that this = linkage is broken. This true of any sending of sequence (RREQ, RREP). =

 

If you do not = lose the unique linkage, then you must consider that an immediately = previous sequence number in a RREQ or RREP is out of date.  In the = example in file non-opt_incSQN2.ppt, my question to Peter is if you know = the packet comes for A and has an old sequence number in (f), you have = the appropriate information (path 1: S-A-D, xmt node A, seq 1) and (path = 2: s-A-I-D xmt A, seq 1).  

 

Q1: How is the = unique node address selected?  Did the WG group have a = security/theoretical discussion on using the loopback IP address versus = other addresses? (e.g. DOS on loopback addresses) If you can point to an = archive discussion, I’m glad to go read it. I would expect that = the sharp minds in this WG would have debated these points. =

 

[Please note I = have tried to state this question to get at the theory behind any = selection of unique node – sequence number linkage – rather = than DYMO versus LOADng question.  I’m glad to learn from = DYMO or LOADng text, but I’m trying to see the theory]. =

 

#2 Sequence = numbers always wrap and sequence number reuse depends on the time and/or = wrap detection.

 

Formats usually = do not impose a particular wrap value.  Common values are zero or = all ones (-1) to aid quick identification of the wrap.  It is not = surprising therefore that:

 

a) Loadng – uses = a simple number format with -1 was wrap value

 

INMU (in my understanding)  wrap goes -2, 0 =      

 

b) Dymo – uses a = TLV format with 0 as both initial number and wrap. =

 

      INMU – the wrap goes -1, = 1

 

Sequence number = time is usually 2* the wrap time so junk can clear from the network. = Therefore the equation is:

 

MAX_SEQ_LIFETIME = =3D 2 * normal_wrap_time

 

Distance vector = routes may encounter route cycling (count to infinity in RIP, BGP MED = harmful/BGP flapping) in certain topologies. Rapidly changing mobile = topologies may cycle through topologies that do and do not cause this = route fluctuation.  The validity timer and max-sequence timer seems = to be addressing this issue.

 

Q2: Am I correct? =

 

The timers in = DYMO-24 are:

 

    =
          =
+------------------------------+-------------+
 =
;            =
 =
|            =
 =
Name           &nb=
sp; |    Value    =
|
        &n=
bsp;     =
+------------------------------+-------------+
 =
;            =
 |        =
ACTIVE_INTERVAL       |   5 =
second  =
|
        &n=
bsp;     =
|         =
MAX_IDLETIME         | 200 =
seconds =
|
        &n=
bsp;     |      =
MAX_SEQNUM_LIFETIME     | 300 seconds =
|
        &n=
bsp;     |     =
ROUTE_RREQ_WAIT_TIME     |  2 seconds  =
|
        &n=
bsp;     | UNICAST_MESSAGE_SENT_TIMEOUT =
|   1 second  =
|
        &n=
bsp;     |      =
RREQ_HOLDDOWN_TIME      |  10 seconds =
|

---------------------------------------------

=

 

Here’s my = set of equations:

  

Validity timer = ::=3Dmax time before route declared invalid

           &= nbsp;   =3D ACTIVE_INTERNAL + MAX_IDLETIME – = (Current_time-Routelast.used)

 

Expired route = ::=3D  route expired, but sequence number cannot be = used

            =   :: =3D valid_time < expired route < = MAX_SEQNUM_TIME

 

Q3: Can you = correct these equations or add to them?

 

Architecture = questions:

 

1. How does = MAX_SEQNUM_TIME interact with the real wrapping functions during fast = node motion to slow node motion so that links come and go (per 2c of = Gabblek, Hofner, Portman and Tan’s diagram (non-opt_incSQN2.pdf) =

 

      As a note to Gabblek et al. (2013), = you may want to examine IEEE Sensor conference papers on this topic. =

 

2.  What = conditions cause all nodes to engage in a sequence number wrap? =  For example, would fast mobility of nodes with fast link breakage = cause these problems?

 

3.  One important = issue is the restart of things after power loss or reboot (likely from = software errors).  Does the node going down require that a sequence = number to be maintained in NVRAM? 

 

4. Is there a reason = for the Address Block TLV route passed through to time out different = that the originating node? If so, does (or does it not) impact the = sequence number wrap.

 

Thank you for aid = in helping me come up to speed on your past discussion, and current = thought.

 

Sue Hares =

------=_NextPart_000_0006_01CDF1EA.9532D430-- From shares@ndzh.com Sun Jan 13 21:15:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C042821F8658 for ; Sun, 13 Jan 2013 21:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.114 X-Spam-Level: * X-Spam-Status: No, score=1.114 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbd8dxu0cXrH for ; Sun, 13 Jan 2013 21:15:07 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 46D0121F85BC for ; Sun, 13 Jan 2013 21:15:07 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: Date: Mon, 14 Jan 2013 00:15:04 -0500 Message-ID: <001201cdf216$1cbd6930$56383b90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CDF1EC.33EB58D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yFhOratnXSvfpSO6Gc0VvxiKSKw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 05:15:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01CDF1EC.33EB58D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Technical issue 2 - order of address in TLV | AddrTLV[1] | the first item in AddrTLV | | AddrTLV[N] | the Nth item in AddrTLV | | AddrTLV[OrigNode] | AddrTLV[1] | | AddrTLV[TargNode] | AddrTLV[2] | Questions: 1. Is this sequence normal for the RFC5444? 2. Is it specified in RFC5444 as a requirement? 3. Why does Henning Rogge consider it bad? He seems to imply that he wants the TLVs numbering to set the order. 3a. Do I understand the format? 3a. Why does it matter? The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) seems come second and provide potential better paths. It would make processing sense to grab the first block to process to get a basic connection (before the nodes move on), and then fine tune). It could be considered "make before you tune it" (a variant of the make before break concept). BGP implementation often try to pack things in the packet so the most important processing comes first. Caveat: I am trying to catch up with your excellent work. If there is previous mail discussion, please let me know. I'll go read it so I can ask better questions. Sue Hares ------=_NextPart_000_0013_01CDF1EC.33EB58D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Technical issue 2 – order of address in TLV

 

|     AddrTLV[1]     = |       the first item in = AddrTLV           = |

|     AddrTLV[N]     = |          the Nth item in = AddrTLV          = |

|  = AddrTLV[OrigNode] = |            =      = AddrTLV[1]          &nb= sp;     |

|  = AddrTLV[TargNode] = |            =      = AddrTLV[2]          &nb= sp;     |

 

 

Questions: =

 

1.  Is this sequence = normal for the RFC5444? 

2.  Is it specified in = RFC5444 as a requirement?

3.  Why does Henning = Rogge consider it bad?

 

    He seems to imply that he wants the TLVs = numbering to set the order.

 

   3a. = Do I understand the format?

 

   3a. = Why does it matter? 

 

The major work of = the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer = optional addresses (a DSR sort-of source routing) seems come second and = provide potential better paths. It would make processing sense to grab = the first block to process to get a basic connection (before the nodes = move on), and then fine tune).  It could be considered “make = before you tune it”  (a variant of the make before break = concept).

 

BGP implementation = often try to pack things in the packet so the most important processing = comes first.

 

Caveat:  I am trying to catch up with your excellent work. If = there is previous mail discussion, please let me know.  I’ll = go read it so I can ask better questions.

 

Sue Hares

 

------=_NextPart_000_0013_01CDF1EC.33EB58D0-- From shares@ndzh.com Sun Jan 13 21:39:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4221F85D7 for ; Sun, 13 Jan 2013 21:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6PzkhNrZnMH for ; Sun, 13 Jan 2013 21:39:36 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0121F85D0 for ; Sun, 13 Jan 2013 21:39:36 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: Date: Mon, 14 Jan 2013 00:39:31 -0500 Message-ID: <002b01cdf219$87895140$969bf3c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CDF1EF.9EB9B1E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yFkFNpfJ7Rr/kQpyrR2HAqt8J+w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [manet] Technical issue 3: default route (Route.pfxlen) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 05:39:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01CDF1EF.9EB9B1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My question: What use cases led to ADOV2 not having a default route included? 0/0 Reasons for: 1) Manet mobile area network to internet access can insert 0/0 default to direct all traffic. The connection of a mobile network can occur from a single point or multiple points. Mobile networks could allow many possible connections to the fixed network e.g. 10), but only have 1-2 active at a time. Did the use cases suggest this scenario? 2) A fixed node detecting a MANET network could easily insert default quickly to quickly set-up Internet connectivity Reason against: 1) Default-free-zones will set-up conflicting defaults within the ADOV2 region. Pro-active algorithms with multiple default can be difficult to design (see multi-homing discussions in IPv6, BGP, 802.11s mesh networks). 2) Extra traffic may be caused as defaults balance between n exit points. 3) Networks would rather have large blocks (e.g. /4 or /8 in v4 or /24 in IPv6) that allow Questions: 1. What use cases did you study to examine the default routing in MANET networks? 2. Did the WG agree that 0/0 is not a useful prefix? What was the reason? 3. What impact did MANET routing or forwarding policy issues have on this decision? 4. Did someone study the amount of bandwidth consumed to converge to a set of default routes? Exit1 Exit 2 Exit 3 | | | | | | ========================================================== | MANET network Node 1 node 2 node 3 node 4 node 5 ========================================================= By converge I mean that Exit1, Exit2, and Exi3 are manet routers with connections to the fixed network. Exit1, Exit2, and exit 3 all want to send the default route into the manet network. What is the result that routing should bring? In other multi-homed cases without additional policy, the following would occur: 1. The traffic from node 1 and node 2 is closest to exit 1, and should be routed to exit 1. 2. The traffic from node 3 is closest to exit 2. Traffic from node 3 should be routed via MANET routing to exit 2. Similarly, node 4 and node 5 are close to exit 3. Traffic from node 4 and 5 should be routed to exit 3. The real issues is the amount of bandwidth and time it takes to converge to multiple default exit points in a reactive protocol. You may get one and then optimize to another one. In multi-homing, IMHO it is best to start out with "why" based on real use cases, and then go through a careful look at topology changes. Did you do this? Is there a paper on this work I should read? 5. Was this a group decision or were there a few opinions? a. If there were opinions were the differing opinions based on use cases or deployment scenarios or were there a few opinions? b. If there were opinions were the differing opinions based on use cases or deployment scenarios? Thank you for any help on default route. In your reply, please be aware that I'm the co-chair of the IDR (BGP) working group. Sue ------=_NextPart_000_002C_01CDF1EF.9EB9B1E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My question:  What use cases = led to ADOV2 not having a default route included?   0/0 =

 

<= span style=3D'font-family:"Courier New"'>Reasons for: =

1)  Manet mobile area network to = internet access can insert 0/0 default to direct all traffic. =

=  

The connection of a mobile network = can occur from a single point or multiple points. Mobile networks could = allow many possible connections to the fixed network e.g. 10), but only = have 1-2 active at a time.  Did the use cases suggest this = scenario?

 

2)  A fixed node detecting a MANET = network could easily insert default quickly to quickly set-up Internet = connectivity   

 

Reason against: =

1)  Default-free-zones will set-up = conflicting defaults within the ADOV2 region. Pro-active algorithms with = multiple default can be difficult to design (see multi-homing = discussions in IPv6, BGP, 802.11s mesh networks).  =

=  

2)  Extra traffic may be caused as = defaults balance between n exit points.  

=  

3)  Networks would rather have large = blocks (e.g. /4 or /8 in v4 or /24 in IPv6) that allow =   

 

<= span style=3D'font-family:"Courier New"'>Questions: =

 

1.  What use cases did you study to = examine the default routing in MANET networks?

=

2.  Did the WG agree that 0/0 is not a = useful prefix?  What was the reason?

 

3.  What impact did MANET routing or = forwarding policy issues have on this decision?  =

 

4.  Did someone study the amount of = bandwidth consumed to converge to a set of default routes?  =

 

Exit1          &n= bsp;         Exit = 2            =         Exit = 3

|           =             &= nbsp; = |            =             &= nbsp; |

|           =             &= nbsp; = |            =             &= nbsp; |

=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=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=3D=3D=3D=3D=3D=3D

|           =    MANET network

 

      Node = 1 node 2      node = 3            node = 4 node 5

=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=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=3D=3D=3D=3D=3D

 

By converge I mean that Exit1, = Exit2, and Exi3 are manet routers with connections to the fixed network. = Exit1, Exit2, and exit 3 all want to send the default route into the = manet network.

 

What is the result that routing = should bring?

 

In other multi-homed cases without = additional policy, the following would occur:

 

1.  The traffic from node 1 and node 2 = is closest to exit 1, and should be routed to exit 1.  =

2.  The traffic from node 3 is closest = to exit 2.  Traffic from node 3 should be routed via MANET routing = to exit 2.  Similarly, node 4 and node 5 are close to exit 3.  = Traffic from node 4 and 5 should be routed to exit 3. =

 

The real issues is the amount of = bandwidth and time it takes to converge to multiple default exit points = in a reactive protocol.

You may get one and then optimize to = another one. In multi-homing, IMHO it is best to start out with = “why” based on real use cases, and then go through a careful = look at topology changes.

 

Did you do this? Is there a paper on = this work I should read?

5.  Was this a group = decision or were there a few opinions? =

a.   If there were opinions = were the differing opinions based on use cases or deployment scenarios = or were there a few opinions? 

b.  If there were opinions were = the differing opinions based on use cases or deployment scenarios? =

 

Thank you for any help on default route.  In your reply, = please be aware that I’m the co-chair of the IDR (BGP) working = group.

 

Sue

------=_NextPart_000_002C_01CDF1EF.9EB9B1E0-- From shares@ndzh.com Sun Jan 13 21:52:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7F21F8605 for ; Sun, 13 Jan 2013 21:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.723 X-Spam-Level: * X-Spam-Status: No, score=1.723 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_05=-1.11, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVA1S7MdPfNV for ; Sun, 13 Jan 2013 21:52:48 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 236B321F85E8 for ; Sun, 13 Jan 2013 21:52:48 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: Date: Mon, 14 Jan 2013 00:52:45 -0500 Message-ID: <004101cdf21b$60689d80$2139d880$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CDF1F1.77968D20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yG1ooffsJJST5TemjEv3rrPLmmQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 05:52:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CDF1F1.77968D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Technical issues 4 - GTSM GTSM started with the observations: 1) that most routing peers operated over adjacent routers, 2) Service providers may not have strict filtering on the link, 3) GSTM is optional and can be configured on a per peer (or group) 4) Both peer routers must implement GSTM 5) Routers support pool for different classified traffic. [section 2. Of RFC5082] To say you "MUST support GTSM" is to say you must have the function, but operators may optionally use it. Question: 1. Henning is an intelligent contributor to the list. Why is Henning indicating the MUST for GTSM should be a SHOULD? How does Henning interpret this text in RFC5082 differently than I do? 2. Have people determine if the adjacency clause has any problems with the node moves away? a. If so, can you point to me to the list discussion? b. If not, why not for GTSM? 3. Some people consider that "Should" DISCARD a message that doesn't fit GTSM allows for special cases that provide their own link checking. Is this Henning's concern? Can someone provide me an example use case for this point. 4. Does a heavy level of link level security in some networks cause the operators of the MANET to consider GTSM to be a problem rather than a solution? Sue ------=_NextPart_000_0042_01CDF1F1.77968D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Technical issues 4 – GTSM =

 

GTSM started with the observations:

1)  that most routing peers operated over adjacent = routers,

2)  Service providers may not have strict filtering on the = link,

3) GSTM is optional and can be configured on a per peer (or = group)

4) Both peer routers must implement GSTM

5) Routers support pool for different classified traffic. =

[section 2. Of RFC5082]

To = say you “MUST support GTSM” is to say you must have the = function, but operators may optionally use it.

Question:

1. Henning is an intelligent contributor to the list.  Why is = Henning indicating the MUST for GTSM should be a SHOULD?  How does = Henning interpret this text in RFC5082 differently than I do? =

2. Have people determine if the adjacency clause has any problems = with the node moves away?

a. If = so, can you point to me to the list discussion?

b. If = not, why not for GTSM?  

3.  Some people consider that “Should” DISCARD a = message that doesn’t fit GTSM allows for special cases that = provide their own link checking.  Is this Henning’s = concern?  Can someone provide me an example use case for this = point.

4.  Does a heavy level of link level security in some networks = cause the operators of the MANET to consider GTSM to be a problem rather = than a solution?

Sue

------=_NextPart_000_0042_01CDF1F1.77968D20-- From shares@ndzh.com Sun Jan 13 22:01:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EFB21F87AB for ; Sun, 13 Jan 2013 22:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.006 X-Spam-Level: * X-Spam-Status: No, score=1.006 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aom70SNOR0x for ; Sun, 13 Jan 2013 22:01:07 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2E5A21F86EA for ; Sun, 13 Jan 2013 22:01:06 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: Date: Mon, 14 Jan 2013 01:01:00 -0500 Message-ID: <004e01cdf21c$87721860$96564920$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CDF1F2.9E9D48E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yG7TLpIk5K7kpSsa2JzzZf1XMgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [manet] Technical issue #6 - Non-optimal routes (warning - long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 06:01:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01CDF1F2.9E9D48E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Warning this is a longer post)=20 Non-optimal routes comes from the post by : Marius (Rice), Rob van = Glabbeek, Peter H=F6fner, Marius Portmann, Wee Lum Tan. W In order to bring us to my questions, I=92m going to provide a synopsis = of what I understand:=20 Their Comments: On-demand/reactive routing protocols (such as AODV, = DYMO and LOADng) often fail to discover the best (shortest) routes [1,2]. The problem is that during route discovery the destination (target) = node does not forward route requests; so, nodes that lie downstream of the destination node frequently create non-optimal routes to the source. Knightly and Miskovic [1] have shown that "poorly selected paths can = have significantly higher routing-metric costs, and their duration can extend = to minute time scales".=20 Glabbeek et al. (2013) have verified that this problem exists in DYMO = and LOADng. As a possible solution, Glabbeek et al. (2013) propose that route = requests are always forwarded, even by nodes generating a route reply [2,3]. The forwarded request should include a flag stating that a reply has already been initiated. In [3] it is shown that this increases the quality of routes. Of course this could increase the overhead of control messages, = but in most of the cases the additional overhead is minimal, since a request floods the entire network anyway. Charlie=92s comments: This is certainly true. There have been = measurements about how far from optimal the routes can be, and if I remember = correctly it's typically somewhere in the neighborhood of 10%, depending on = congestion and node mobility. Charlie: [Always forwarded route requests] can be made into an optional behavior, controllable either by a system-wide configuration parameter, = or a new RREQ option. I would not expect that it should be the default = behavior Sue=92s Comments:=20 1. Distance Vector (DV) vector by distribution may fail to create = optimal routes if multicast distribution is not complete. BGP has this problem = as well. It is a tradeoff of message flood and optimal routes. 2. Best optimal routes are from Link-state OLSRv2, ISIS, or others with tuning to reduce the flood Questions:=20 1. Where are the use cases for the MANET protocols that provide these tradeoffs for congestion, node mobility, link loss and flooding? =20 2. How is MANET judging the tradeoffs?=20 3. Stretch is a description of non-optimality. For example the stretch value of 120 means the path is 20% longer. What is the normal stretch in MANET? How does this compare with BGP=92s stretch?=20 4. Is the MANET WG looking for stretch range for their reactive = protocol? =20 =20 Thank you for any comments. Again, if I have missed papers or a = discussion =96 just let me know and I will find and read.=20 =20 Sue Hares =20 ------=_NextPart_000_004F_01CDF1F2.9E9D48E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(Warning this is a longer post) =

Non-optimal routes comes from the = post by : Marius = (Rice), Rob van Glabbeek, Peter H=F6fner, =A0Marius Portmann, Wee Lum = Tan. =A0W

In order to bring us to my = questions, I’m going to provide a synopsis of what I understand: =

Their Comments:=A0=A0 = On-demand/reactive = routing protocols (such as AODV, DYMO and LOADng) often fail = to discover the best (shortest) routes [1,2].

 The = problem is that during route discovery the destination (target) = node does not forward route requests; so, nodes that lie downstream = of the destination node frequently create non-optimal routes to the = source. Knightly and Miskovic [1] have shown that "poorly = selected paths can have significantly higher routing-metric costs, and = their duration can extend to minute time = scales". 

Glabbeek et al. (2013) =A0have = verified that this problem exists in DYMO and = LOADng.

 As a possible solution, = Glabbeek=A0 et al. (2013) propose that route requests are always = forwarded, even by nodes generating a route reply [2,3]. The = forwarded request should include a flag stating that a reply has already = been initiated. In [3] it is shown that this increases the quality of = routes. Of course this could increase the overhead of control = messages, but in most of the cases the additional overhead is = minimal, since a request floods the entire network = anyway.

Charlie’s = comments:=A0 This is certainly true.  There have been = measurements about how far from optimal the routes can be, and if I = remember correctly it's typically somewhere in the neighborhood of 10%, = depending on congestion and node = mobility.

Charlie:=A0 [Always forwarded route = requests] can be made into an optional behavior, controllable either by = a system-wide configuration parameter, or a new RREQ option.  I = would not expect that it should be the default = behavior

Sue’s Comments: =

1.  Distance Vector (DV) =A0vector by = distribution may fail to create optimal routes if multicast distribution = is not complete. =A0BGP has this problem as well. It is a tradeoff of = message flood and optimal routes.

2.  Best optimal routes are from = Link-state OLSRv2, ISIS, or others with tuning to reduce the = flood

Questions: =

1.  Where are the use cases for the = MANET protocols that provide these tradeoffs for congestion, node = mobility, link loss and flooding?=A0

2.  How is MANET judging the tradeoffs? =

3.  Stretch is a description of = non-optimality. For example the stretch value of 120 means the path is = 20% longer. What is the normal stretch in MANET? How does this compare = with BGP’s stretch?

4.  Is the MANET WG looking for stretch = range for their reactive protocol? =A0

 

Thank you for any comments. Again, = if I have missed papers or a discussion – just let me know and I = will find and read.

 

Sue = Hares

 

------=_NextPart_000_004F_01CDF1F2.9E9D48E0-- From shares@ndzh.com Sun Jan 13 22:18:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98221F8841 for ; Sun, 13 Jan 2013 22:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxZiBJQieV32 for ; Sun, 13 Jan 2013 22:18:34 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6A35921F8833 for ; Sun, 13 Jan 2013 22:18:34 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: Date: Mon, 14 Jan 2013 01:18:30 -0500 Message-ID: <006701cdf21e$f9679bf0$ec36d3d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01CDF1F5.1094C840" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yHOEeq5WlW8KqQEyV0kzG9K6ctw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [manet] Technical issue #7 - AODV can loose route replies - warning longer post X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 06:18:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0068_01CDF1F5.1094C840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This post refers to Comments by: Marius (Rice), Rob van Glabbeek, Peter H=F6fner, Marius Portmann, Wee Lum Tan. T To start the question, let me recap the key points in the words of = Glabbeek et al. (2013)=20 Glabbeek et al. (2013) Comments: AODV can lose route replies ( http://www.ietf.org/mail-archive/web/manet/current/msg05702.html).=20 The reason is that route replies are only forwarded by an intermediate = node when the node updates its routing table. This problem has partly been solved in DYMO and LOADng by increasing sequence numbers when initiating = a route reply. However, a careful analysis shows that replies can still = be lost; yielding again non-optimal routes or route discovery failures. = Namely, if one route reply overtakes another, i.e., a newer reply reaches a node earlier than an older one, then the older route reply is dropped [4]. =20 A solution consists of intermediate nodes always forwarding route = replies. Surely, forwarding (unicasting) replies increases the number of messages = in the network. But, (a) route discovery is more likely and (b) re-sending = a route request to establish a route would yield another broadcast cycle, which is much more expensive w.r.t. network load. Charlie=92s comments: I guess you mean that the two RREPs under = discussion were going towards two distinct Originating Nodes. Otherwise, it would = be good for the older RREP to be dropped. For the case of two distinct Originating Nodes, the behavior is a protocol error that needs to be = fixed. "Always forwarding" RREPs is one alternative, and certainly preferable = to a new Route Discovery cycle in the network. I am confident that there is a better solution, and I will work on = finding and specifying it. Sue=92s Comments/questions =20 1. (Comment) Charlie=92s issue about two RREP going to two distinct Originating nodes, match the research I recall for the 802.11s investigations into reactive protocol. In real testing, two distinct originating nodes with a fixed node connection inserted the subnet (or network) route into the reactive protocol. This is a much simpler case than the default route insertion mentioned in my technical issue 3. Of course, these same two nodes (fixed/mobile), can a whole routing table = from two originating nodes. =20 =20 2. Comment: RREP to going to two originating nodes IMHO seems to = be a problem that is basic. Charlie says ADOV-25 has it fixed. LoadNG always sends the RREP back to the same originator.=20 =20 3. Question: Has the WG provided many scenarios like those of = Glabbeek et al. (2013) to validate this works? Are there timing issues?=20 4. Question: is there ever a connectivity problem with if the older route being dropped? Can you provide the scenario?=20 =20 5. What is the cost of intermediate nodes always forwarding route replies?=20 =20 The topologies do matter in DV. Have these algorithms been run multiple topologies. =20 =20 Again =96 if this has been discussed on list, or in presentations, or = papers =96 just let me know. I=92ll go look it up, and come back with better = questions.=20 =20 Thank you again=20 =20 Sue Hares=20 =20 ------=_NextPart_000_0068_01CDF1F5.1094C840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This = post refers to Comments by: Marius (Rice), Rob van Glabbeek, Peter = H=F6fner, =A0Marius Portmann, Wee Lum Tan. =A0T

To start = the question, let me recap the key points in the words of Glabbeek et = al. (2013)

Glabbeek = et al. (2013) Comments:=A0=A0 AODV can lose route replies (http://www.ietf.org/mail-archive/web/manet/current/msg057= 02.html). 

The reason is that route = replies are only forwarded by an intermediate node when = the node updates its routing table.  This problem has partly = been solved in DYMO and LOADng by increasing sequence numbers when = initiating a route reply.=A0 However, a careful analysis shows that = replies can still be lost; yielding again non-optimal routes or route = discovery failures. Namely, if one route reply overtakes another, = i.e., a newer reply reaches a node earlier than an older one, then the = older route reply is dropped [4].=A0

 A solution = consists of intermediate nodes always forwarding route = replies. Surely, forwarding (unicasting) replies increases the = number of messages in the network. But, (a) route discovery is more = likely and (b) re-sending a route request to establish a route would = yield another broadcast  cycle, which is much more expensive w.r.t. = network load.

Charlie’s = comments:=A0 I guess you mean that the two RREPs under discussion = were going towards two distinct Originating Nodes.  Otherwise, it = would be good for the older RREP to be dropped. =A0For the case of two = distinct Originating Nodes, the behavior is a protocol error that needs = to be fixed.  "Always forwarding" RREPs is one = alternative, and certainly preferable to a new Route Discovery cycle in = the network.


I am confident that = there is a better solution, and I will work on finding and specifying = it.

Sue’s = Comments/questions=A0

1.      = (Comment) Charlie’s issue about two RREP going to = two distinct Originating nodes, match the research I recall for the = 802.11s investigations into=A0 reactive protocol. In real testing, two = distinct originating nodes with a fixed node connection inserted the = subnet (or network) route into the reactive protocol.=A0 =A0This is a = much simpler case than the default route insertion mentioned in my = technical issue 3.=A0 =A0Of course, these same two nodes (fixed/mobile), = can a whole routing table from two originating nodes.=A0 =

 

2.      = Comment:=A0 RREP to going to two originating nodes IMHO = seems to be a problem that is basic. Charlie says ADOV-25 has it = fixed.=A0 LoadNG always sends the RREP back to the same originator. =

 

3.      = Question: Has the WG provided many scenarios like those = of Glabbeek =A0et al. (2013) to validate this works?=A0 Are there timing = issues?

4.      = Question: is there ever a connectivity problem with if = the older route being dropped? Can you provide the scenario? =

=A0

5.      = What is the cost of intermediate nodes always forwarding = route replies?

 

The topologies do matter in DV.=A0 Have these = algorithms been run multiple topologies.

 

 

Again – if this has been discussed on list, or in = presentations, or papers – just let me know.=A0 I’ll go look = it up, and come back with better questions.

 

Thank you again

 

Sue Hares

 

------=_NextPart_000_0068_01CDF1F5.1094C840-- From shares@ndzh.com Sun Jan 13 22:35:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5722A21F8803 for ; Sun, 13 Jan 2013 22:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3VyJIV+q8CA for ; Sun, 13 Jan 2013 22:35:54 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9851F21F87BA for ; Sun, 13 Jan 2013 22:35:53 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> In-Reply-To: <001201cdf216$1cbd6930$56383b90$@ndzh.com> Date: Mon, 14 Jan 2013 01:35:45 -0500 Message-ID: <00e101cdf221$62b4efc0$281ecf40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01CDF1F7.79E21C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMlLeyJ7Bo7DfQol46ZRyeiu3Vd/5WZ5nDQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 06:35:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E2_01CDF1F7.79E21C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just one additional comment - BGP uses TLVs in its messages . This is the ordering of the TLVs to be processed, not the TLVs. Sue From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 14, 2013 12:15 AM To: manet@ietf.org Subject: [manet] Hares Technical Question 2: order of address in TLV Technical issue 2 - order of address in TLV | AddrTLV[1] | the first item in AddrTLV | | AddrTLV[N] | the Nth item in AddrTLV | | AddrTLV[OrigNode] | AddrTLV[1] | | AddrTLV[TargNode] | AddrTLV[2] | Questions: 1. Is this sequence normal for the RFC5444? 2. Is it specified in RFC5444 as a requirement? 3. Why does Henning Rogge consider it bad? He seems to imply that he wants the TLVs numbering to set the order. 3a. Do I understand the format? 3a. Why does it matter? The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) seems come second and provide potential better paths. It would make processing sense to grab the first block to process to get a basic connection (before the nodes move on), and then fine tune). It could be considered "make before you tune it" (a variant of the make before break concept). BGP implementation often try to pack things in the packet so the most important processing comes first. Caveat: I am trying to catch up with your excellent work. If there is previous mail discussion, please let me know. I'll go read it so I can ask better questions. Sue Hares ------=_NextPart_000_00E2_01CDF1F7.79E21C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just one additional comment – BGP uses = TLVs in its messages . This is the ordering of the TLVs to be processed, = not the TLVs.  

Sue

 

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Monday, January 14, 2013 12:15 = AM
To: manet@ietf.org
Subject: [manet] Hares = Technical Question 2: order of address in = TLV

 

Technical issue 2 – order of address in TLV

 

|     AddrTLV[1]     = |       the first item in = AddrTLV           = |

|     AddrTLV[N]     = |          the Nth item in = AddrTLV          = |

|  = AddrTLV[OrigNode] = |            =      = AddrTLV[1]          &nb= sp;     |

|  = AddrTLV[TargNode] = |            =      = AddrTLV[2]          &nb= sp;     |

 

 

Questions: =

 

1.  Is this sequence = normal for the RFC5444? 

2.  Is it specified in = RFC5444 as a requirement?

3.  Why does Henning = Rogge consider it bad?

 

    He seems to imply that he wants the TLVs = numbering to set the order.

 

   3a. = Do I understand the format?

 

   3a. = Why does it matter? 

 

The major work of = the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer = optional addresses (a DSR sort-of source routing) seems come second and = provide potential better paths. It would make processing sense to grab = the first block to process to get a basic connection (before the nodes = move on), and then fine tune).  It could be considered “make = before you tune it”  (a variant of the make before break = concept).

 

BGP implementation = often try to pack things in the packet so the most important processing = comes first.

 

Caveat:  I am trying to catch up with your excellent work. If = there is previous mail discussion, please let me know.  I’ll = go read it so I can ask better questions.

 

Sue Hares

 

------=_NextPart_000_00E2_01CDF1F7.79E21C10-- From henning.rogge@fkie.fraunhofer.de Sun Jan 13 23:15:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3C21F8845 for ; Sun, 13 Jan 2013 23:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeqUx1wX6GIq for ; Sun, 13 Jan 2013 23:15:19 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0D85421F8844 for ; Sun, 13 Jan 2013 23:15:19 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TueGL-0000dT-HN for manet@ietf.org; Mon, 14 Jan 2013 08:15:17 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TueGL-0001IR-Eh for manet@ietf.org; Mon, 14 Jan 2013 08:15:17 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 08:15:17 +0100 Message-ID: <50F3B07E.7040806@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 08:15:10 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> In-Reply-To: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090607030202020902080308" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16485/Mon Jan 14 06:42:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e39381ef53debe75338dede4cc492f79 Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 07:15:20 -0000 --------------ms090607030202020902080308 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 06:03 AM, Susan Hares wrote: > a)Loadng =96 uses a simple number format with -1 was wrap value > > INMU (in my understanding) wrap goes -2, 0 I think you are wrong in this... Loadng goes -1, 0, 1 without any gap.=20 Similar to OLSRv1 and OLSRv2. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090607030202020902080308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQwNzE1MTVaMCMGCSqGSIb3DQEJBDEWBBSy96k1sbsKPDA9rirGn5gJVBc4kjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAAbzDVtg/DCviokiAgOntSUWuudxo0MJxggMxHVlyoCkA 05M/Iku2kUgIc6slmAFF+pN5dCzh/0GzOgCJfucTyI9txivoIrzNdeLeNNkXqhrQh5Vw0i+U 2IJoXFkxULD2rnvvoJjpoV5WpSs+76Ke9tSsALOc8CnZQgrXC+NWoQBzeuJplF3sPx9s1Mlm vdSCvZm4NvXAjEcpyz8FY65c3rPAC9H4rBhEISvh9lXdyXAGuwd61SDWvOCtplimGdRoRbMz R5Txk61Aop58NaAIaC3/9bPbfjcQ7PnM3BINPjb20LF6SgJjqQ26Lij/yYsh465GKKkBWuAN SZVxetxmMgAAAAAAAA== --------------ms090607030202020902080308-- From henning.rogge@fkie.fraunhofer.de Sun Jan 13 23:20:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695F021F8551 for ; Sun, 13 Jan 2013 23:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR5PEBMprk74 for ; Sun, 13 Jan 2013 23:20:12 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C653D21F8731 for ; Sun, 13 Jan 2013 23:20:11 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TueL5-000279-4z for manet@ietf.org; Mon, 14 Jan 2013 08:20:11 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TueL5-0001Q2-2H for manet@ietf.org; Mon, 14 Jan 2013 08:20:11 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 08:20:10 +0100 Message-ID: <50F3B1A9.4050205@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 08:20:09 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> In-Reply-To: <001201cdf216$1cbd6930$56383b90$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090402040903080805080807" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16485/Mon Jan 14 06:42:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 0cd0ad97dfb2426e440047df9b1aa998 Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 07:20:13 -0000 --------------ms090402040903080805080807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 06:15 AM, Susan Hares wrote: > > Technical issue 2 =96 order of address in TLV > > | AddrTLV[1] | the first item in AddrTLV | > > | AddrTLV[N] | the Nth item in AddrTLV | > > | AddrTLV[OrigNode] | AddrTLV[1] | > > | AddrTLV[TargNode] | AddrTLV[2] | > > Questions: > > 1.Is this sequence normal for the RFC5444? The normal thing for RFC5444 should be that protocols do NOT specify a=20 mandatory order of Addresses or TLVs. > 2.Is it specified in RFC5444 as a requirement? > > 3.Why does Henning Rogge consider it bad? > > He seems to imply that he wants the TLVs numbering to set the orde= r. No, I did not. I asked for dropping ANY requirements of AODVv2 to the order of=20 addresses and the split into address blocks. There are two advantages of this: 1.) You can use a generic parser to parse AODVv2. 2.) The IMPLEMENTATION can decide on the order of addresses to allow=20 better compression of the binary RFC5444 message. > 3a. Why does it matter? Yes, I think it does. > The major work of the RREQ/RREP seems to have a short block of 2 > ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) > seems come second and provide potential better paths. It would make > processing sense to grab the first block to process to get a basic > connection (before the nodes move on), and then fine tune). It could b= e > considered =93make before you tune it=94 (a variant of the make before= > break concept). > > BGP implementation often try to pack things in the packet so the most > important processing comes first. Implementations could do this, but the protocol specification should not = demand it. The protocol specification should just say "add address X=20 with TLV Y to signal Z". Making the protocol depend on position and split of addresses is a step=20 backward from a TLV format towards a binary format where parts of the=20 information is hidden in the order of non-annotated fields. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090402040903080805080807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQwNzIwMDlaMCMGCSqGSIb3DQEJBDEWBBSX8D4p55yYs5l4ZSylNYlFf1EYoDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAUh/f9c+OK6dpxWUdu7ke6Rz0Q0ipgSJIAF6KU4AqqeAc PAm3mgC9yhTTmS9SuK3T4d7wvnSVYiloKNRebXjaUptx1FARwtEBvsiGxIRp5Xb4V/W05AfG z68Wv4BSyOXwVryjuxXGmtz6Qi65sFJx1ygKcteucQ6xW9HA7OHU7zhCMi9yzB42UJ/eV3Jv 30ZDwNhvAOUANVyyD4jxfbDHV9Bbrf6b7zPMcz7NloxEqrk/x/gUJa291VYpGqG/Coe4o0Td WRLFG7ljuRCmkEnCrOHQrUZyeixfteNmqxVDq948hEdwvFZcCaj2fzUh9WLNFv6l4D3aXPFp NFqCU8qS8AAAAAAAAA== --------------ms090402040903080805080807-- From henning.rogge@fkie.fraunhofer.de Sun Jan 13 23:34:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820F21F885C for ; Sun, 13 Jan 2013 23:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iktdMQuCZh-p for ; Sun, 13 Jan 2013 23:34:30 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 861A621F8855 for ; Sun, 13 Jan 2013 23:34:29 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TueYu-0006j0-TJ for manet@ietf.org; Mon, 14 Jan 2013 08:34:28 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TueYu-0001j8-Qg for manet@ietf.org; Mon, 14 Jan 2013 08:34:28 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 08:34:28 +0100 Message-ID: <50F3B4FF.20408@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 08:34:23 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <004101cdf21b$60689d80$2139d880$@ndzh.com> In-Reply-To: <004101cdf21b$60689d80$2139d880$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020507010402080902090007" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16485/Mon Jan 14 06:42:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: cf4e294f566e9b0166dbdd65a574298f Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 07:34:34 -0000 --------------ms020507010402080902090007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 06:52 AM, Susan Hares wrote: > 1.Henning is an intelligent contributor to the list. Why is Henning > indicating the MUST for GTSM should be a SHOULD? How does Henning > interpret this text in RFC5082 differently than I do? Because its a layer violation in the context of RFC5444. AODVv2 defines a MESSAGE for RFC5444. You can (and often do) run=20 multiple protocols on top of RFC5444 which each define its own message. A common example for this is running RFC 6130 (NHDP) and OLSRv2 (or AODVv= 2). RFC5444 combines this messages and aggregates them into packets, which=20 are then sent as UDP packets on the network. If protocols which defines messages make mandatory assumtions about the=20 IP packets, you can get conflicts between them. I would suggest putting=20 GTSM into AODVv2 security considerations as a proposal, so the=20 IMPLEMENTOR (who controls which protocols work together on the same=20 RFC5444 port) can decide if he wants GTSM or not. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020507010402080902090007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQwNzM0MjZaMCMGCSqGSIb3DQEJBDEWBBQs7UC0SWauNMSITM/2fN0bwRa8pzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAMAOF0ecc5fZVFDuiNNCtchhajmKxtCNdge4FOWxzCfkU 85ybDQ5CNeDS+txM1XYzDcfWXGg1Z5ULnrgqip3ZIZAjIrbO3IVS88UwYXohcvKWT8lRElyI wqpYhlkhI6KsgTSBxtAQ8bbCIyeWW1cqripuEQd18QHgVMMgTBQZ6scdV3YFXhdvosa0ebaz U3ZIJ8M8uIq2aaNFZzS9XMXldqqaeNdR0og33BbBddqgsrdWXbnJNpa3lV86ugiCbsqY14Ck Y3IZoGrDPbjnzmNnzHwPAPOMP5AY2UH2pSnQJMLhSt8jCnARG63y/Z7oX99BHnNYuSR+8o7w Qx+O8a9QvAAAAAAAAA== --------------ms020507010402080902090007-- From henning.rogge@fkie.fraunhofer.de Sun Jan 13 23:45:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EC321F8844 for ; Sun, 13 Jan 2013 23:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oevcTLvsG1cP for ; Sun, 13 Jan 2013 23:45:26 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A420421F87C8 for ; Sun, 13 Jan 2013 23:45:25 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TuejV-0001nf-03 for manet@ietf.org; Mon, 14 Jan 2013 08:45:25 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TuejU-00026v-Td for manet@ietf.org; Mon, 14 Jan 2013 08:45:24 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 08:45:24 +0100 Message-ID: <50F3B793.40801@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 08:45:23 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <002b01cdf219$87895140$969bf3c0$@ndzh.com> In-Reply-To: <002b01cdf219$87895140$969bf3c0$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040400070909030103000702" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16485/Mon Jan 14 06:42:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 85239c378c801ec17cfcd0d5bc49a059 Subject: Re: [manet] Technical issue 3: default route (Route.pfxlen) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 07:45:27 -0000 --------------ms040400070909030103000702 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 06:39 AM, Susan Hares wrote: > *Questions: * > > 1.What use cases did you study to examine the default routing in MANET > networks? I think having multiple default gateways (towards your backbone) is a=20 common use case. Both for high volume/data networks and for low powered=20 networks down to sensor networks (RPL for example supports multiple=20 internet gateways I think). > 2.Did the WG agree that 0/0 is not a useful prefix? What was the reaso= n? I do NOT think we agreed that 0/0 is NOT a useful prefix. > 3.What impact did MANET routing or forwarding policy issues have on thi= s > decision? The main problem with prefixes in reactive routing protocols is that=20 they can prevent the trigger of a "no route available" event, which in=20 turn triggers the route discovery. There are administrative solutions to this problem, but its more=20 difficult to solve for reactive protocols than proactive ones. I see two good options to work on this for AODVv2: a) we say that "announcing prefixes" is out of scope for AODVv2 and that = it will be addressed in an extension document. I think LOADng is going=20 this way too. b) we add a solution to AODVv2 that allows us to announce prefixes (with = certain restrictions like administrative black holes) > 4.Did someone study the amount of bandwidth consumed to converge to a > set of default routes? > > Exit1 Exit 2 Exit 3 > > | | | > > | | | > > =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=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=3D=3D=3D=3D=3D=3D > > | MANET network > > Node 1 node 2 node 3 node 4 node 5 > > =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=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=3D=3D=3D=3D=3D > > By converge I mean that Exit1, Exit2, and Exi3 are manet routers with > connections to the fixed network. Exit1, Exit2, and exit 3 all want to > send the default route into the manet network. > > What is the result that routing should bring? > > In other multi-homed cases without additional policy, the following > would occur: > > 1.The traffic from node 1 and node 2 is closest to exit 1, and should b= e > routed to exit 1. > > 2.The traffic from node 3 is closest to exit 2. Traffic from node 3 > should be routed via MANET routing to exit 2. Similarly, node 4 and > node 5 are close to exit 3. Traffic from node 4 and 5 should be routed= > to exit 3. > > The real issues is the amount of bandwidth and time it takes to converg= e > to multiple default exit points in a reactive protocol. > > You may get one and then optimize to another one. In multi-homing, IMHO= > it is best to start out with =93why=94 based on real use cases, and the= n go > through a careful look at topology changes. > > Did you do this? Is there a paper on this work I should read? Typically routing protocols just dump the traffic into the "closest" or=20 "currently known" outgoing gateway. If you need load-balancing, fairness = or need to care for certain restrictions of gateways, you need=20 additional information and protocol parts (we have implemented an extension like this in the OLSR.org codebase for = OLSRv1 and a few people are still improving it) > 5.Was this a group decisionor were there a few opinions? > > > a. If there were opinions were the differing opinions based on us= e > cases or deployment scenarios or were there a few opinions? > > > b.If there were opinions were the differing opinions based on use= > cases or deployment scenarios? > > Thank you for any help on default route. In your reply, please be awar= e > that I=92m the co-chair of the IDR (BGP) working group. I don't think the 0/0 route should be that special... there are other=20 kinds of prefixes that might be relevant for AODVv2 too, for example /64 = prefixes in IPv6 networks to allow each AODVv2 node to announce a=20 complete subnet attached to the mesh node. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040400070909030103000702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQwNzQ1MjNaMCMGCSqGSIb3DQEJBDEWBBSVTH6xTbYjMyOOLB4dV/H3Me/PTTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAe/surqb7Mvl9nw+FXqvg6nXqspS8k9U+q7G1rt2d+Qr5 +7l2V2DPyxCJij8qv/RuarkFlinwSkKSYpYlCUlaQFPHoH5E7iRuwcLLwRZQV6aV+59vZDBD HzDBFrk9XEaLlwkFUnuJbBLpfBaTIwVN7zuk+ma40787Oe5TZMWIfWpnP33c6TAhVboCtRee wdw/kY/cyGLn9a7Szc9bOf3micm9cRmMFG4BB0/GhonJBG8xTGKHmPKN9DDPNDQP80KH3Qs6 h1SRaV4V/jnUaFlMjTdz3vJPctuqW188r95xgZ4K+AU1idH8xX/Guz95/06BlT7jgsNW6SOQ rJ70WZzEKwAAAAAAAA== --------------ms040400070909030103000702-- From abdussalambaryun@gmail.com Mon Jan 14 03:44:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C30A21F85FD for ; Mon, 14 Jan 2013 03:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuslnHZ2F7w2 for ; Mon, 14 Jan 2013 03:44:19 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 112A921F858A for ; Mon, 14 Jan 2013 03:44:18 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so3396934vba.41 for ; Mon, 14 Jan 2013 03:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1jknOhyhTQqdUN++cqYBUEUUzE0ChcBmTqJ/dxq7wSY=; b=l7XFZleTc03ApeS+NQmRi3ZhEjXcVVf177fkio4/YeZxHlmILzklz7moaPuNglxFGI P6YhS+Fnn63P7TKwAKkKzg3zlJeuRLjhx+Zq6hyhQ9zfRUL0Ud7Mj87iu/Am4z48+feu Kj3HoRjyCZxJTNex7K9qL0jVX7suyPkX7WqNfuhp6qrAFF8TRDT7LauEDTeHmhLVLrQT o9RYIjfBX1vxqTsKsiROVB4RTHolvn4ZEYjPTwIZVy6iOynpl37fW1KPwqu4h+lfOGg4 ZVzuUJA3xZX+tB8NChLXsRkpxxZGTVX9ADfoxvzIlu7QcVxRvKPKUVHTjEULdRpvNXzn ajOQ== MIME-Version: 1.0 Received: by 10.52.76.73 with SMTP id i9mr88084505vdw.25.1358163858429; Mon, 14 Jan 2013 03:44:18 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 14 Jan 2013 03:44:18 -0800 (PST) In-Reply-To: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> Date: Mon, 14 Jan 2013 12:44:18 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 11:44:20 -0000 Hi Sue, Thanks for discussion, I am not claver but will try my best to answer, comments in line; On 1/14/13, Susan Hares wrote: > > Technical issue 1: Sequence numbers > > > > > DYMO-25 Text: > > > > An AODVv2 Sequence Number is an unsigned integer maintained by each AODVv2 > router. This sequence number guarantees the temporal order of routing > information to maintain loop-free routes. The value zero (0) is reserved > to > indicate that the SeqNum for a destination address is unknown. > correct, similar in both AODVv2 and LOADng, > > > Question text: > > > > In a monotonically increasing sequence number you have three issues: > > > > 1 - unique sequence linkage to node/port/update(e.g. LSA) > > 2 - sequence number wrap > > 3 - when to sequence number increment. > > #1 - unique node - sequence number linkage > > From the DYMO text, the sequence number is monotonically increases per node > address. If you lose the node address-sequence number link, it appears that > this linkage is broken. This true of any sending of sequence (RREQ, RREP). > the above paragraph uses the words *you-lose* as dymo-router or not sure !!! IMO, not exactly broken, but the destination Sequence Number (SN) is invalid, because the route is active. The link considered broken only if route is invalid. If a node loses it's own SN then all links are broken. > If you do not lose the unique linkage, then you must consider that an > immediately previous sequence number in a RREQ or RREP is out of date. In > the example in file non-opt_incSQN2.ppt, my question to Peter is if you > know > the packet comes for A and has an old sequence number in (f), you have the > appropriate information (path 1: S-A-D, xmt node A, seq 1) and (path 2: > s-A-I-D xmt A, seq 1). > > > > Q1: How is the unique node address selected? Did the WG group have a > security/theoretical discussion on using the loopback IP address versus > other addresses? (e.g. DOS on loopback addresses) If you can point to an > archive discussion, I'm glad to go read it. I would expect that the sharp > minds in this WG would have debated these points. I don't think there are discussion in this issue, not sure :( > > > > [Please note I have tried to state this question to get at the theory > behind > any selection of unique node - sequence number linkage - rather than DYMO > versus LOADng question. I'm glad to learn from DYMO or LOADng text, but > I'm > trying to see the theory]. > > > > #2 Sequence numbers always wrap and sequence number reuse depends on the > time and/or wrap detection. > > > > Formats usually do not impose a particular wrap value. Common values are > zero or all ones (-1) to aid quick identification of the wrap. It is not > surprising therefore that: > > > > a) Loadng - uses a simple number format with -1 was wrap value > > > > INMU (in my understanding) wrap goes -2, 0 > LOADng SHOULD go -1, 0, 1, but still not followed through the document, I'll leave/wait the authors to answer, > > > b) Dymo - uses a TLV format with 0 as both initial number and wrap. > > > > INMU - the wrap goes -1, 1 > me too, > > > Sequence number time is usually 2* the wrap time so junk can clear from the > network. Therefore the equation is: > > > > MAX_SEQ_LIFETIME = 2 * normal_wrap_time > IMHO, I think; MAX_SEQ_LIFETIME < normal_wrap_time > > > Distance vector routes may encounter route cycling (count to infinity in > RIP, BGP MED harmful/BGP flapping) in certain topologies. Rapidly changing > mobile topologies may cycle through topologies that do and do not cause > this > route fluctuation. The validity timer and max-sequence timer seems to be > addressing this issue. > > Q2: Am I correct? > its also max-seq addresses the problem of losing SN as mentioned in draft-dymo-25, and validitytime addresses the RFC5497 issues. > > > The timers in DYMO-24 are: > > > > +------------------------------+-------------+ > | Name | Value | > +------------------------------+-------------+ > | ACTIVE_INTERVAL | 5 second | > | MAX_IDLETIME | 200 seconds | > | MAX_SEQNUM_LIFETIME | 300 seconds | > | ROUTE_RREQ_WAIT_TIME | 2 seconds | > | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | > | RREQ_HOLDDOWN_TIME | 10 seconds | > > --------------------------------------------- > > > > Here's my set of equations: > > > > Validity timer ::=max time before route declared invalid > > = ACTIVE_INTERNAL + MAX_IDLETIME - > (Current_time-Routelast.used) this timer is flexible depends on the originator of such TLV, see RFC5497 > > Expired route ::= route expired, but sequence number cannot be used > > :: = valid_time < expired route < MAX_SEQNUM_TIME I don't want to mix the information, but I think draft-dymo-25 has specified the conditions, > > Q3: Can you correct these equations or add to them? > IMHO, I don't think we SHOULD follow equations, but the use-case, where it always will depend on the netwok parameters. > > Architecture questions: > > 2. What conditions cause all nodes to engage in a sequence number wrap? > For example, would fast mobility of nodes with fast link breakage cause > these problems? > not sure what is the problem here, but yes while breaks are frequent the wrap will become, > > > 3. One important issue is the restart of things after power loss or reboot > (likely from software errors). Does the node going down require that a > sequence number to be maintained in NVRAM? this is mentioned in draft-dymo-25, yes it requires storage, > > 4. Is there a reason for the Address Block TLV route passed through to time > out different that the originating node? If so, does (or does it not) > impact > the sequence number wrap. It should not time out before the origin, and specified by origin. It is not related to wrap of SN. > > > > Thank you for aid in helping me come up to speed on your past discussion, > and current thought. > Thanks to you too, AB > > > Sue Hares > > From abdussalambaryun@gmail.com Mon Jan 14 04:17:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0744021F8648 for ; Mon, 14 Jan 2013 04:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3eXgEDw+uTx for ; Mon, 14 Jan 2013 04:17:07 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4721F8650 for ; Mon, 14 Jan 2013 04:17:07 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so3432239vbb.17 for ; Mon, 14 Jan 2013 04:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EqolS5rOHr0/LIf/0s3tCul/UZTEHpgAM2HUdl1qscY=; b=aHVLSXF0jy5QB05Z9zemTrfb40+2Ph0zsJZC+Vrz4v87U487AMuVRwW+OuVRivVBQX 0vXUw12EINVr7fkERaVvQjzo1s6p5osqTKiSVVRscJJA4WxPsxV0dDVMTaCEqZdu1rWM MRc7Lzj3IGuT8P7krUympUXw4eYMvsZ+fLAiZlFpyNO/M/wYX02371pHho3qvH4p+1Wq FZ88JnY+0O20JOZqM/UMUXwyuKpN2vEEKoVz8nPwiWQ5pvbLtLS0YXP3Ogoh5tBH2YzJ 8bDv0SLVBSBg6+3c55siRC3ykEaSWM+l+1KD1TCb1tCmEUUg6c1XUcX2qom1tndRydei xq2g== MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr105083937veb.43.1358165826706; Mon, 14 Jan 2013 04:17:06 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 14 Jan 2013 04:17:06 -0800 (PST) In-Reply-To: <50F3B1A9.4050205@fkie.fraunhofer.de> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 13:17:06 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:17:08 -0000 On 1/14/13, Henning Rogge wrote: > The normal thing for RFC5444 should be that protocols do NOT specify a > mandatory order of Addresses or TLVs. IMO, the RFC5444 states that it is the protocol to define/specify its RFC5444 messages, so this makes RFC5444 format general, but if its updated to want the MANET routing protocol to follow a general order way also, then I think the RFC5444 will be more limiting protocol's activity. AB From henning.rogge@fkie.fraunhofer.de Mon Jan 14 04:30:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4521F890F for ; Mon, 14 Jan 2013 04:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-ZQZWFvJ8dw for ; Mon, 14 Jan 2013 04:30:15 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 8430D21F867A for ; Mon, 14 Jan 2013 04:30:15 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TujB8-00052F-TS for manet@ietf.org; Mon, 14 Jan 2013 13:30:14 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TujB8-0001bC-Qp for manet@ietf.org; Mon, 14 Jan 2013 13:30:14 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 13:30:14 +0100 Message-ID: <50F3FA50.1070506@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 13:30:08 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070704010506030806000600" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338 Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:30:16 -0000 --------------ms070704010506030806000600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 01:17 PM, Abdussalam Baryun wrote: > On 1/14/13, Henning Rogge wrote: >> The normal thing for RFC5444 should be that protocols do NOT specify a= >> mandatory order of Addresses or TLVs. > > IMO, the RFC5444 states that it is the protocol to define/specify its > RFC5444 messages, so this makes RFC5444 format general, but if its > updated to want the MANET routing protocol to follow a general order > way also, then I think the RFC5444 will be more limiting protocol's > activity. I think you are missing the point of a TLV format. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070704010506030806000600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxMjMwMTJaMCMGCSqGSIb3DQEJBDEWBBR42CjOw9ocS5/pvMhBkl99cZJxyjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAEmEazaX9G7dwKASE5N5/gYVIF0Ne3M6OVx1AO1qf0Dvb gxsvOJhNz6ZrHYRqsX4xdSMpZO8wIa6xCq3wQ55ItALWlgLM+mZQihVP2YHK/PF2gqbKIejk kvQONSL4jLrNBWCzazZMskl5iHMp+xz+olvSTjzwtZbK7FrOsjijR/ej4bPtgMAr7wLkNm0v uBXTCDHur5TfhsZCEb0HZIrByCj6wNptPlNjxhSAOhYFESXN6pa5nHRUHBPxf0/9eJF0lgdn H9iWzDjs+y1swBMg7cvvjgMwLyParga+0e3TuDFdYnZlUc6fX49Nsl7skKJBe4Y+clNhQ9L+ FuxYAxHo6gAAAAAAAA== --------------ms070704010506030806000600-- From henning.rogge@fkie.fraunhofer.de Mon Jan 14 04:42:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3851721F8505 for ; Mon, 14 Jan 2013 04:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2aUO8ubk8Hq for ; Mon, 14 Jan 2013 04:42:42 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF3C21F841B for ; Mon, 14 Jan 2013 04:42:41 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TujNB-00019G-0j for manet@ietf.org; Mon, 14 Jan 2013 13:42:41 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TujNA-0001xN-Ue for manet@ietf.org; Mon, 14 Jan 2013 13:42:40 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 13:42:40 +0100 Message-ID: <50F3FD3F.2090803@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 13:42:39 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010408080506090501090707" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b17092e937cef22d8bf42b2c04946c57 Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:42:43 -0000 --------------ms010408080506090501090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 12:44 PM, Abdussalam Baryun wrote: >> An AODVv2 Sequence Number is an unsigned integer maintained by each AO= DVv2 >> router. This sequence number guarantees the temporal order of routing= >> information to maintain loop-free routes. The value zero (0) is reser= ved >> to >> indicate that the SeqNum for a destination address is unknown. > > correct, similar in both AODVv2 and LOADng, I don't think LOADng use a "magic number" within the sequence numbers. 0 = has no special meaning as a sequence number for LOADng. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010408080506090501090707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxMjQyMzlaMCMGCSqGSIb3DQEJBDEWBBS/btJuF/d+6q8qRWXOS4rwV4G/CDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwtcrZCrMOYs30DBzvkKmOpfzLMyM+nyW20tVclbakB2h eujIqyEzzyKZ2wza4pxdUZ3zgJS3C4oc4ekpqJBOmyqqY5sACwxyUnGitcw7wQkDB8vThqIw m1rlu2I4hE0EXvk28XTL43Sl8zQh8sa29qYKSw0CI8IcVsiTf20WT9KPc5NaTFubp4acTTf4 vdzjXzgzqup/MHonDt3SZVgyiTeXV2+dzqBn4TE2FxCjYu5raQLzTP3cuGlf2OZez14hWzuq +YlhJRlPLwaQ8tUdu7JhvTpqAErukuHc4lEY7m1zuIO9X0qRiNrO/5FxkVye7PeplNwNIVvT GiZLCOR/oAAAAAAAAA== --------------ms010408080506090501090707-- From shares@ndzh.com Mon Jan 14 06:19:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAC21F8870 for ; Mon, 14 Jan 2013 06:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu41Wx-DhkMC for ; Mon, 14 Jan 2013 06:19:26 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE021F8864 for ; Mon, 14 Jan 2013 06:19:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" , References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> In-Reply-To: <50F3B07E.7040806@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:19:20 -0500 Message-ID: <012401cdf262$2625ca20$72715e60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwmNk0YWA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:19:28 -0000 Henning: Thank you for the quick response. Below I have the text sections from=20 http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt How should I interpret this text? Your comment is=20 -1 (0xFFFF), 0, 1 =20 How does it work? =20 Let us assume S1 rotates through MAX_VALUE (0xFFFF, 0, 1) , and S2 stays at 0xCFFF.=20 The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF=20 Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore s1 = is > S2 Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > 0x3FFF=20 Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case = follows How do you know it wrapped and hit the previous value? =20 Am I missing something in the LOADng text? Or is the text missing something?=20 Sue=20 ------------------ In section 8 it says:=20 Each LOADng Router maintains a single sequence number, which must be included in each RREQ or RREP message it generates. Each LOADng Router MUST make sure that no two messages (both RREQ and RREP) are generated with the same sequence number, and MUST generate sequence numbers such that these are monotonically increasing. This sequence number is used as freshness information for when comparing routes to the LOADng Router having generated the message. However, with a limited number of bits for representing sequence numbers, wrap-around (that the sequence number is incremented from the maximum possible value to zero) can occur. To prevent this from interfering with the operation of the protocol, the following MUST be observed. The term MAXVALUE designates in the following the largest possible value for a sequence number. The sequence number S1 is said to be "greater than" (denoted '>') the sequence number S2 if: S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE/2 And on page 46 | RREQ.seq-num | | 16 bits, hence MAXVALUE | | | | (Section 8) is 65535. =20 The Hex value for 66535 is 0xFFFF.=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Monday, January 14, 2013 2:15 AM To: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) On 01/14/2013 06:03 AM, Susan Hares wrote: > a)Loadng =96 uses a simple number format with -1 was wrap value > > INMU (in my understanding) wrap goes -2, 0 I think you are wrong in this... Loadng goes -1, 0, 1 without any gap.=20 Similar to OLSRv1 and OLSRv2. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From henning.rogge@fkie.fraunhofer.de Mon Jan 14 06:22:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EC921F85F3 for ; Mon, 14 Jan 2013 06:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofCX41f3Al07 for ; Mon, 14 Jan 2013 06:22:43 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B61F021F85D7 for ; Mon, 14 Jan 2013 06:22:42 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tukvy-00011J-3K; Mon, 14 Jan 2013 15:22:42 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tukvy-0004kM-0c; Mon, 14 Jan 2013 15:22:42 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:22:41 +0100 Message-ID: <50F414B0.1030501@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 15:22:40 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> In-Reply-To: <012401cdf262$2625ca20$72715e60$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080204010303080307060109" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 5471e3af7d52574b30ec22437ed00ccd Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:22:44 -0000 --------------ms080204010303080307060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 03:19 PM, Susan Hares wrote: > Henning: > > Thank you for the quick response. Below I have the text sections from > > http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt > > How should I interpret this text? Your comment is > > -1 (0xFFFF), 0, 1 > > How does it work? > > Let us assume S1 rotates through MAX_VALUE > (0xFFFF, 0, 1) , and S2 stays at 0xCFFF. > > The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF > Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF > S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 > > Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore s= 1 is > S2 > Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > 0x3FFF > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case = follows > > How do you know it wrapped and hit the previous value? > > Am I missing something in the LOADng text? Or is the text missing > something? > > Sue > > > ------------------ > > In section 8 it says: > > Each LOADng Router maintains a single sequence number, which must be= > included in each RREQ or RREP message it generates. Each LOADng > Router MUST make sure that no two messages (both RREQ and RREP) are= > generated with the same sequence number, and MUST generate sequence= > numbers such that these are monotonically increasing. This sequenc= e > number is used as freshness information for when comparing routes t= o > the LOADng Router having generated the message. > > However, with a limited number of bits for representing sequence > numbers, wrap-around (that the sequence number is incremented from > the maximum possible value to zero) can occur. To prevent this fro= m > interfering with the operation of the protocol, the following MUST = be > observed. The term MAXVALUE designates in the following the larges= t > possible value for a sequence number. The sequence number S1 is sa= id > to be "greater than" (denoted '>') the sequence number S2 if: > > S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR > S1 < S2 AND S2 - S1 > MAXVALUE/2 > > And on page 46 > > | RREQ.seq-num | | 16 bits, hence MAXVALUE = | > | | > | (Section 8) is 65535. > > The Hex value for 66535 is 0xFFFF. > > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Henning Rogge > Sent: Monday, January 14, 2013 2:15 AM > To: manet@ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence num= bers > (warning long post) > > On 01/14/2013 06:03 AM, Susan Hares wrote: >> a)Loadng - uses a simple number format with -1 was wrap value >> >> INMU (in my understanding) wrap goes -2, 0 > > I think you are wrong in this... Loadng goes -1, 0, 1 without any gap. > Similar to OLSRv1 and OLSRv2. I think section 8 of the LOADng draft answers your question. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080204010303080307060109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNDIyNDBaMCMGCSqGSIb3DQEJBDEWBBRkDY4LCZLDpNsdnVagGl0G7rGnRjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAS+xar4e456RjOdaSnOZIeOIwhElG+HkcLdfQGr6EVJt3 pZedilKyDag8+N9Pjn/3kYw7MVB49vw+5jMmHkFItOuIfzb9dkpwAw3O4XdTHvL5XtejI6+P 1X5AmZ7dDtsASxOHAkTsTUQHcqgI6CXqCd9zesBsNSJiFCxyUoY3zMJzGIvrFy/Zrt0wvWMF 6eLYQdckPJNz1dfHIJ3/hBnxyPmP6nGZMMHjoOKab1AFuROmp6WVF0oCfpORBk53d9udw1Dk OW//J8cJoty2C1uTh4O3aWyi8n9grtRsKR3LBp8kxf926m279eNZEN53yaAVmMC86Tf0aS+b Fhyr6ZkraAAAAAAAAA== --------------ms080204010303080307060109-- From shares@ndzh.com Mon Jan 14 06:23:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF0E21F8917 for ; Mon, 14 Jan 2013 06:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.884 X-Spam-Level: X-Spam-Status: No, score=0.884 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkTtp2vEm7Mu for ; Mon, 14 Jan 2013 06:23:39 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEB121F8717 for ; Mon, 14 Jan 2013 06:23:39 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" , References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> In-Reply-To: <50F3B1A9.4050205@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:23:36 -0500 Message-ID: <012601cdf262$bdcd2f30$39678d90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMlLeyJ7Bo7DfQol46ZRyeiu3Vd/wHko46zlYtDo2A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:23:41 -0000 Henning:=20 Thank you for your explanation. I understanding your concern with the = TLVs. I just wanted to understand if there was something else regarding implementations because implementations do work toward efficient = processing. Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Monday, January 14, 2013 2:20 AM To: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV On 01/14/2013 06:15 AM, Susan Hares wrote: > > Technical issue 2 =96 order of address in TLV > > | AddrTLV[1] | the first item in AddrTLV | > > | AddrTLV[N] | the Nth item in AddrTLV | > > | AddrTLV[OrigNode] | AddrTLV[1] | > > | AddrTLV[TargNode] | AddrTLV[2] | > > Questions: > > 1.Is this sequence normal for the RFC5444? The normal thing for RFC5444 should be that protocols do NOT specify a mandatory order of Addresses or TLVs. > 2.Is it specified in RFC5444 as a requirement? > > 3.Why does Henning Rogge consider it bad? > > He seems to imply that he wants the TLVs numbering to set the = order. No, I did not. I asked for dropping ANY requirements of AODVv2 to the order of = addresses and the split into address blocks. There are two advantages of this: 1.) You can use a generic parser to parse AODVv2. 2.) The IMPLEMENTATION can decide on the order of addresses to allow = better compression of the binary RFC5444 message. > 3a. Why does it matter? Yes, I think it does. > The major work of the RREQ/RREP seems to have a short block of 2=20 > ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) = > seems come second and provide potential better paths. It would make=20 > processing sense to grab the first block to process to get a basic=20 > connection (before the nodes move on), and then fine tune). It could=20 > be considered =93make before you tune it=94 (a variant of the make = before=20 > break concept). > > BGP implementation often try to pack things in the packet so the most=20 > important processing comes first. Implementations could do this, but the protocol specification should not demand it. The protocol specification should just say "add address X = with TLV Y to signal Z". Making the protocol depend on position and split of addresses is a step backward from a TLV format towards a binary format where parts of the information is hidden in the order of non-annotated fields. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From shares@ndzh.com Mon Jan 14 06:26:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5818821F8925 for ; Mon, 14 Jan 2013 06:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.859 X-Spam-Level: X-Spam-Status: No, score=0.859 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARb+4Zlk8vdC for ; Mon, 14 Jan 2013 06:26:04 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC84221F8917 for ; Mon, 14 Jan 2013 06:26:04 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" , References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> In-Reply-To: <50F3B4FF.20408@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:26:01 -0500 Message-ID: <012801cdf263$14855960$3d900c20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLNxnmL6cVAglJr/WkVENy2ida7LwH+PYT4ljlG86A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:26:05 -0000 Henning:=20 Again, thank you for aiding my understanding.=20 Do I understand from this message that RFC5444 should be the protocol running GTSM? Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Monday, January 14, 2013 2:34 AM To: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM On 01/14/2013 06:52 AM, Susan Hares wrote: > 1.Henning is an intelligent contributor to the list. Why is Henning=20 > indicating the MUST for GTSM should be a SHOULD? How does Henning=20 > interpret this text in RFC5082 differently than I do? Because its a layer violation in the context of RFC5444. AODVv2 defines a MESSAGE for RFC5444. You can (and often do) run = multiple protocols on top of RFC5444 which each define its own message. A common example for this is running RFC 6130 (NHDP) and OLSRv2 (or = AODVv2). RFC5444 combines this messages and aggregates them into packets, which = are then sent as UDP packets on the network. If protocols which defines messages make mandatory assumtions about the = IP packets, you can get conflicts between them. I would suggest putting = GTSM into AODVv2 security considerations as a proposal, so the IMPLEMENTOR = (who controls which protocols work together on the same RFC5444 port) can decide if he wants GTSM or not. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From shares@ndzh.com Mon Jan 14 06:34:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49321F8803 for ; Mon, 14 Jan 2013 06:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.837 X-Spam-Level: X-Spam-Status: No, score=0.837 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+exa9y1OHal for ; Mon, 14 Jan 2013 06:34:26 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id ABCDA21F8780 for ; Mon, 14 Jan 2013 06:34:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" , References: <002b01cdf219$87895140$969bf3c0$@ndzh.com> <50F3B793.40801@fkie.fraunhofer.de> In-Reply-To: <50F3B793.40801@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:34:22 -0500 Message-ID: <012a01cdf264$3f095500$bd1bff00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFs1WOqnX2Qr09soDk5w0IQVsDbHgHdC4B7mPwzZEA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Technical issue 3: default route (Route.pfxlen) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:34:27 -0000 Henning: Implementing insertion of external routes (any prefix) is a well-known = case from ISIS, OSPF, or OLSR.=20 Load balancing in a reactive protocols needs metric passed to measure = the distance to the gateway. I agree that you can do this in a reactive protocol, but the design needs to be carefully done. What I think you = are saying, is that this part is being handed off to a reactive protocol addition at this point. =20 Did I understand correctly? =20 I do agree that practically, people do want to insert external routes. = I would love to see the scenarios for the reactive protocol addition to = LOADng or AODV2. Did I miss this discussion in the mail list archives?=20 Thank you,=20 Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Monday, January 14, 2013 2:45 AM To: manet@ietf.org Subject: Re: [manet] Technical issue 3: default route (Route.pfxlen) On 01/14/2013 06:39 AM, Susan Hares wrote: > *Questions: * > > 1.What use cases did you study to examine the default routing in MANET = > networks? I think having multiple default gateways (towards your backbone) is a = common use case. Both for high volume/data networks and for low powered = networks down to sensor networks (RPL for example supports multiple internet = gateways I think). > 2.Did the WG agree that 0/0 is not a useful prefix? What was the = reason? I do NOT think we agreed that 0/0 is NOT a useful prefix. > 3.What impact did MANET routing or forwarding policy issues have on=20 > this decision? The main problem with prefixes in reactive routing protocols is that = they can prevent the trigger of a "no route available" event, which in turn triggers the route discovery. There are administrative solutions to this problem, but its more = difficult to solve for reactive protocols than proactive ones. I see two good options to work on this for AODVv2: a) we say that "announcing prefixes" is out of scope for AODVv2 and that = it will be addressed in an extension document. I think LOADng is going this = way too. b) we add a solution to AODVv2 that allows us to announce prefixes (with certain restrictions like administrative black holes) > 4.Did someone study the amount of bandwidth consumed to converge to a=20 > set of default routes? > > Exit1 Exit 2 Exit 3 > > | | | > > | | | > > = =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=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=3D=3D=3D=3D=3D=3D > > | MANET network > > Node 1 node 2 node 3 node 4 node 5 > > = =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=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=3D=3D=3D=3D=3D > > By converge I mean that Exit1, Exit2, and Exi3 are manet routers with=20 > connections to the fixed network. Exit1, Exit2, and exit 3 all want to = > send the default route into the manet network. > > What is the result that routing should bring? > > In other multi-homed cases without additional policy, the following=20 > would occur: > > 1.The traffic from node 1 and node 2 is closest to exit 1, and should=20 > be routed to exit 1. > > 2.The traffic from node 3 is closest to exit 2. Traffic from node 3=20 > should be routed via MANET routing to exit 2. Similarly, node 4 and=20 > node 5 are close to exit 3. Traffic from node 4 and 5 should be=20 > routed to exit 3. > > The real issues is the amount of bandwidth and time it takes to=20 > converge to multiple default exit points in a reactive protocol. > > You may get one and then optimize to another one. In multi-homing,=20 > IMHO it is best to start out with =93why=94 based on real use cases, = and=20 > then go through a careful look at topology changes. > > Did you do this? Is there a paper on this work I should read? Typically routing protocols just dump the traffic into the "closest" or "currently known" outgoing gateway. If you need load-balancing, fairness = or need to care for certain restrictions of gateways, you need additional information and protocol parts (we have implemented an extension like this in the OLSR.org codebase for OLSRv1 and a few people are still improving it) > 5.Was this a group decisionor were there a few opinions? > > > a. If there were opinions were the differing opinions based on = use > cases or deployment scenarios or were there a few opinions? > > > b.If there were opinions were the differing opinions based on = use > cases or deployment scenarios? > > Thank you for any help on default route. In your reply, please be=20 > aware that I=92m the co-chair of the IDR (BGP) working group. I don't think the 0/0 route should be that special... there are other = kinds of prefixes that might be relevant for AODVv2 too, for example /64 = prefixes in IPv6 networks to allow each AODVv2 node to announce a complete subnet attached to the mesh node. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From henning.rogge@fkie.fraunhofer.de Mon Jan 14 06:35:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8024A21F88E6 for ; Mon, 14 Jan 2013 06:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHXai+mBa-Au for ; Mon, 14 Jan 2013 06:35:04 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68321F895F for ; Mon, 14 Jan 2013 06:35:04 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tul7v-0004SU-2P; Mon, 14 Jan 2013 15:35:03 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tul7u-00053o-Vv; Mon, 14 Jan 2013 15:35:02 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:35:02 +0100 Message-ID: <50F41795.3030601@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 15:35:01 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <012601cdf262$bdcd2f30$39678d90$@ndzh.com> In-Reply-To: <012601cdf262$bdcd2f30$39678d90$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030304020806080607030409" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 63d11b563531d75ada9d42d73b6da78e Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:35:05 -0000 --------------ms030304020806080607030409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 03:23 PM, Susan Hares wrote: > Henning: > > Thank you for your explanation. I understanding your concern with the = TLVs. Its both a matter of "whats the purpose of a TLV format if parts of the=20 information is NOT in the TLVs" and a matter of efficient implementation.= > I just wanted to understand if there was something else regarding > implementations because implementations do work toward efficient proces= sing. MANET protocols are mostly used with wireless transmission, so a lot of=20 MANET implementations care more about "airtime" than "processing time". There is quite a bit potential for more compact transmissions in=20 RFC5444, but this depends highly on the order of the addresses and their = split into different address blocks. If the protocol mandates a certain order/split for semantic reasons, it=20 blocks these optimizations. Example: lets assume we have a RFC5444 message with 20 addresses, 10.0.0.1 to=20 10.0.0.10 and 10.1.0.1 to 10.1.0.10 If we put them into a single block in a random order, we most likely can = only use the common prefix "10." for compression, which safes us ~20=20 bytes (minus 2 bytes overhead in the header). If we split them into two address blocks, one for 10.0.0.x and one for=20 10.1.0.x, each of the address blocks have a 3 byte common header, which=20 safes a total of ~60 bytes (minus 4 bytes overhead in the first header,=20 minus 6 bytes for the second header). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030304020806080607030409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNDM1MDFaMCMGCSqGSIb3DQEJBDEWBBS33I94plLAGv4UJzH6yNaTOFqq4TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAo4CRgC+6kF0bmMbhlWnQgr21ylFmx0GsvkfeEhLUMDcm /qcwvK6uc0seLpEaf0yJ0fvcebQp7Wu+794zhp0Nwn8kMwkG3IK1Vgv5nYuAeP5CoKrTVVOd 6d9Z5hoQ11I43gBy2LKaA4NBZWnCnlOnNeb4E5yMIx4Zb+eUHS9uq3Y7fZfFSY6MYUE9dZso +UaGj4H7nSaHztomS6B0212CyWM7qkzvfUozuywM/F3zgRRmiBgPxIh227S7ezVqQgqOnW90 9WDIT+9Nma9kw9EXBw47J1anaruw0dil7/3/KOTeQ0X6PSOh+oy7uX5DF6+Lqvvb/08uFiKl YYehRmhRXgAAAAAAAA== --------------ms030304020806080607030409-- From shares@ndzh.com Mon Jan 14 06:36:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE52A21F8803 for ; Mon, 14 Jan 2013 06:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.817 X-Spam-Level: X-Spam-Status: No, score=0.817 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JZrzaCuTMEc for ; Mon, 14 Jan 2013 06:36:19 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8321F88B2 for ; Mon, 14 Jan 2013 06:36:19 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" , References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3FD3F.2090803@fkie.fraunhofer.de> In-Reply-To: <50F3FD3F.2090803@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:36:13 -0500 Message-ID: <012c01cdf264$829756a0$87c603e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAFr477lAYNyXauY1MtxIA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:36:20 -0000 Henning: Thank you for clarifying this. I did understand that from your first message. Please see that response.=20 Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Monday, January 14, 2013 7:43 AM To: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) On 01/14/2013 12:44 PM, Abdussalam Baryun wrote: >> An AODVv2 Sequence Number is an unsigned integer maintained by each=20 >> AODVv2 router. This sequence number guarantees the temporal order of = >> routing information to maintain loop-free routes. The value zero (0) = >> is reserved to indicate that the SeqNum for a destination address is=20 >> unknown. > > correct, similar in both AODVv2 and LOADng, I don't think LOADng use a "magic number" within the sequence numbers. 0 = has no special meaning as a sequence number for LOADng. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From henning.rogge@fkie.fraunhofer.de Mon Jan 14 06:36:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2F821F8992 for ; Mon, 14 Jan 2013 06:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzG5Wdgo5DkI for ; Mon, 14 Jan 2013 06:36:22 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id F23E621F88B2 for ; Mon, 14 Jan 2013 06:36:21 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tul9B-00062F-Ba; Mon, 14 Jan 2013 15:36:21 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tul9B-0005AC-8q; Mon, 14 Jan 2013 15:36:21 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:36:20 +0100 Message-ID: <50F417E4.8070304@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 15:36:20 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> <012801cdf263$14855960$3d900c20$@ndzh.com> In-Reply-To: <012801cdf263$14855960$3d900c20$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050505040402090803050805" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:36:23 -0000 --------------ms050505040402090803050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 03:26 PM, Susan Hares wrote: > Henning: > > Again, thank you for aiding my understanding. > > Do I understand from this message that RFC5444 should be the protocol > running GTSM? Yes, I think GTSM is a security consideration (and option) for RFC5444. So AODVv2 could suggest using it for RFC5444, but I don't think its the=20 place to mandate its usage. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050505040402090803050805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNDM2MjBaMCMGCSqGSIb3DQEJBDEWBBSQG8Vzrv1yDCQakyKfQC6rT5iA9DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEATIfPkXKxT+MjhBzp+XFPXEXddvfQ7cDvoe55E6kwbsg1 P+CAbAXXNcAr5DYuBr8/Ibs/O8PjbTrmJMjxV0i98PqmGqyXhHCSu3i1cSSLLmBzwf/GAMA3 GetW8fkDjJ3BY7aoCjzpoeX+4c2Pv7jhg4TlYJksY3JtBRiLlTdMTAs5jYJwhsnFsN1JAa9V 0g2DXB2gUi7VbqP7fqkIC/8r7pAM1nsPN/pEUO0BiUypDsNf3pauOHLWgkBK61hqQh0SpaLX Fp8P0P/06A6E/cwmjPrGuAabtkOoolJMpTawYDzaMwd3RXhsXokSF8054Vq3FKo1HEVNTgPt 8QxVJjVltgAAAAAAAA== --------------ms050505040402090803050805-- From henning.rogge@fkie.fraunhofer.de Mon Jan 14 06:40:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9270B21F88E2 for ; Mon, 14 Jan 2013 06:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOTVacHfCWO5 for ; Mon, 14 Jan 2013 06:40:41 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 92ABD21F8803 for ; Mon, 14 Jan 2013 06:40:41 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TulDM-000742-Vi; Mon, 14 Jan 2013 15:40:40 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TulDM-0005IC-Sw; Mon, 14 Jan 2013 15:40:40 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:40:40 +0100 Message-ID: <50F418E7.2080002@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 15:40:39 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <002b01cdf219$87895140$969bf3c0$@ndzh.com> <50F3B793.40801@fkie.fraunhofer.de> <012a01cdf264$3f095500$bd1bff00$@ndzh.com> In-Reply-To: <012a01cdf264$3f095500$bd1bff00$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030909030607070005030100" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Cc: manet@ietf.org Subject: Re: [manet] Technical issue 3: default route (Route.pfxlen) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:40:42 -0000 --------------ms030909030607070005030100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 03:34 PM, Susan Hares wrote: > Henning: > > Implementing insertion of external routes (any prefix) is a well-known = case > from ISIS, OSPF, or OLSR. Yes. > Load balancing in a reactive protocols needs metric passed to measure t= he > distance to the gateway. I agree that you can do this in a reactive > protocol, but the design needs to be carefully done. What I think you = are > saying, is that this part is being handed off to a reactive protocol > addition at this point. > > Did I understand correctly? I say we should do it right (allow any kind of prefix, maybe with some=20 necessary administrative rules) or postpone it to an extension draft. Building a special case for a single internet gateway (and no other=20 prefixes) sounds like a bad idea. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030909030607070005030100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNDQwMzlaMCMGCSqGSIb3DQEJBDEWBBR71T4rqOZY1nskN/a+wkhoHfwuIjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAFP/t7xEol96D6T2IMb3GQEyxUTzsL3lDseU3UMMgnIk1 +bDfoUegOGsVSn7tzD/IReOAERK49AwNsad8CqZumBV82L1MkbHX8sRvkwLMRpp9gvdxEDj2 I54l6x0CwO9YiofbGcqd1qsGTqwVs2GZ94TAQ0tFc5mXvpLGtrhe5jdlk7UX2eOth0qGAWtI iSm3UlDPz/8pgaaOlm6Flvd9KZnkNXDX4zTn3rGcbtU1u0fNgAdOP7LUFQfybTr2qnYTeaMX uXXJXnlBeidrsiLfiUgH+XGn00gAe0/QiU09gas2t7dm1nFQaivyeqlva+9+V2Ux9mZA/TXD 0h8w2ZvxsgAAAAAAAA== --------------ms030909030607070005030100-- From shares@ndzh.com Mon Jan 14 06:41:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBBD21F86B6 for ; Mon, 14 Jan 2013 06:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9EKfYn4ORjn for ; Mon, 14 Jan 2013 06:41:19 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4889421F8925 for ; Mon, 14 Jan 2013 06:41:19 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F414B0.1030501@fkie.fraunhofer.de> In-Reply-To: <50F414B0.1030501@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:41:12 -0500 Message-ID: <013701cdf265$354fe6e0$9fefb4a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCkV35Opi0BYFA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:41:20 -0000 Henning:=20 Is section 8 only dealing with origination of sequence numbers? How = does LOADng handle reception of the sequence I listed below?=20 Assume some pesky broken MANET router keeps sending/forwarding a packet = with same origin and sequence number 0xCFFFF.=20 Sue=20 [Snip]=20 > > -1 (0xFFFF), 0, 1 > > How does it work? > > Let us assume S1 rotates through MAX_VALUE > (0xFFFF, 0, 1) , and S2 stays at 0xCFFF. > > The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF > Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF > S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 > > Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore = s1 is > S2 > Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > 0x3FFF > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case = follows > > How do you know it wrapped and hit the previous value? > > Am I missing something in the LOADng text? Or is the text missing > something? > > Sue > > > ------------------ > > In section 8 it says: > > Each LOADng Router maintains a single sequence number, which must = be > included in each RREQ or RREP message it generates. Each LOADng > Router MUST make sure that no two messages (both RREQ and RREP) = are > generated with the same sequence number, and MUST generate = sequence > numbers such that these are monotonically increasing. This = sequence > number is used as freshness information for when comparing routes = to > the LOADng Router having generated the message. > > However, with a limited number of bits for representing sequence > numbers, wrap-around (that the sequence number is incremented from > the maximum possible value to zero) can occur. To prevent this = from > interfering with the operation of the protocol, the following MUST = be > observed. The term MAXVALUE designates in the following the = largest > possible value for a sequence number. The sequence number S1 is = said > to be "greater than" (denoted '>') the sequence number S2 if: > > S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR > S1 < S2 AND S2 - S1 > MAXVALUE/2 > > And on page 46 > > | RREQ.seq-num | | 16 bits, hence MAXVALUE = | > | | > | (Section 8) is 65535. > > The Hex value for 66535 is 0xFFFF. > > [snip]=20 > > I think you are wrong in this... Loadng goes -1, 0, 1 without any gap. > Similar to OLSRv1 and OLSRv2. I think section 8 of the LOADng draft answers your question. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From shares@ndzh.com Mon Jan 14 06:44:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8889A21F88C7 for ; Mon, 14 Jan 2013 06:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.784 X-Spam-Level: X-Spam-Status: No, score=0.784 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQkhVb5q7Gwi for ; Mon, 14 Jan 2013 06:44:25 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AA0A521F854F for ; Mon, 14 Jan 2013 06:44:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <012601cdf262$bdcd2f30$39678d90$@ndzh.com> <50F41795.3030601@fkie.fraunhofer.de> In-Reply-To: <50F41795.3030601@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:44:22 -0500 Message-ID: <014201cdf265$a4b70950$ee251bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMlLeyJ7Bo7DfQol46ZRyeiu3Vd/wHko46zAj18NB4C4wn9wJViRYNg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:44:26 -0000 Henning: Thank you for the example. The text from RFC5444 and AODV had led me = to your example and the power of compression.=20 My original question is whether the code was more efficient if certain = TLVs fell before others.=20 Thank you again for the careful and well-written explanations. Sue =20 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: Monday, January 14, 2013 9:35 AM To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV On 01/14/2013 03:23 PM, Susan Hares wrote: > Henning: > > Thank you for your explanation. I understanding your concern with the TLVs. Its both a matter of "whats the purpose of a TLV format if parts of the=20 information is NOT in the TLVs" and a matter of efficient = implementation. > I just wanted to understand if there was something else regarding > implementations because implementations do work toward efficient processing. MANET protocols are mostly used with wireless transmission, so a lot of=20 MANET implementations care more about "airtime" than "processing time". There is quite a bit potential for more compact transmissions in=20 RFC5444, but this depends highly on the order of the addresses and their = split into different address blocks. If the protocol mandates a certain order/split for semantic reasons, it=20 blocks these optimizations. Example: lets assume we have a RFC5444 message with 20 addresses, 10.0.0.1 to=20 10.0.0.10 and 10.1.0.1 to 10.1.0.10 If we put them into a single block in a random order, we most likely can = only use the common prefix "10." for compression, which safes us ~20=20 bytes (minus 2 bytes overhead in the header). If we split them into two address blocks, one for 10.0.0.x and one for=20 10.1.0.x, each of the address blocks have a 3 byte common header, which=20 safes a total of ~60 bytes (minus 4 bytes overhead in the first header,=20 minus 6 bytes for the second header). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From henning.rogge@fkie.fraunhofer.de Mon Jan 14 06:47:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCDB21F8202 for ; Mon, 14 Jan 2013 06:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpoyGTFlo6jt for ; Mon, 14 Jan 2013 06:47:35 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6886D21F88C7 for ; Mon, 14 Jan 2013 06:47:34 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TulK1-00010C-HE; Mon, 14 Jan 2013 15:47:33 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TulK1-0005UG-ET; Mon, 14 Jan 2013 15:47:33 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:47:32 +0100 Message-ID: <50F41A84.1080904@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 15:47:32 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> In-Reply-To: <012401cdf262$2625ca20$72715e60$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020206030804000104080709" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 607149b96c849f66a82590e883281293 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:47:36 -0000 --------------ms020206030804000104080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sorry for not the bad answer to your first mail. See explanation below...= On 01/14/2013 03:19 PM, Susan Hares wrote: > Henning: > > Thank you for the quick response. Below I have the text sections from > > http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt > > How should I interpret this text? Your comment is > > -1 (0xFFFF), 0, 1 > > How does it work? > > Let us assume S1 rotates through MAX_VALUE > (0xFFFF, 0, 1) , and S2 stays at 0xCFFF. > > The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF > Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF > S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 > > Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore s= 1 is > S2 > Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > 0x3FFF > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case = follows >> The sequence number S1 is said to be "greater than" (denoted '>') >> the sequence number S2 if: >> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE= /2 If this formula is "true", S1 is considered larger than S2. If this formula is "false", S1 is considered to be smaller than S2. Its a single boolean formula, no "two cases". @Ulrich Herberg: maybe the formula could be presented like this to make it more clear? (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE/2) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020206030804000104080709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNDQ3MzJaMCMGCSqGSIb3DQEJBDEWBBS4TMq0PGTsj7SUlVgMx6GTJGFhjDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAW6/0YZqnJKRsbR11b+jOpxCJ6RLU7plnYrT3MkRSTjnz wvYAnVm8voE27VQNZM+03MPJ6LONalR6XCmR688sigz4hcbaL5fRQvIykwmwKgcCso4cTTK9 vnTm+yo56wDY3Y1sWp1g/Zd/fu0LDuKmrYtDkbBvuWqgAXj6kBawcmnwu5biN3EzbDLQx9/u qRcOGzMqzr/hTay6TKHHcnzqhmpQazPgHvuaNt+Vp1IyKH4LuEuWGCwCZieTdL4po6kQwfss 9PIwSQJ4FFE6eMtIT9Blq6TmIZfSaIjjIU/DmKuH5xHq+KUe+bsvdAA8OUt/8fan280KgUfY I/k0jNKiNQAAAAAAAA== --------------ms020206030804000104080709-- From henning.rogge@fkie.fraunhofer.de Mon Jan 14 06:49:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910FF21F8953 for ; Mon, 14 Jan 2013 06:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utXffK1P0-Hk for ; Mon, 14 Jan 2013 06:49:05 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A975D21F844C for ; Mon, 14 Jan 2013 06:49:04 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TulLU-00012V-1X; Mon, 14 Jan 2013 15:49:04 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TulLT-0005Ut-V4; Mon, 14 Jan 2013 15:49:03 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:49:03 +0100 Message-ID: <50F41ADE.1030902@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 15:49:02 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <012601cdf262$bdcd2f30$39678d90$@ndzh.com> <50F41795.3030601@fkie.fraunhofer.de> <014201cdf265$a4b70950$ee251bf0$@ndzh.com> In-Reply-To: <014201cdf265$a4b70950$ee251bf0$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060302050101060707010204" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d11929bbb37d0bf82123645737fe3651 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:49:05 -0000 --------------ms060302050101060707010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 03:44 PM, Susan Hares wrote: > Henning: > > Thank you for the example. The text from RFC5444 and AODV had led me = to > your example and the power of compression. > > My original question is whether the code was more efficient if certain = TLVs > fell before others. > > Thank you again for the careful and well-written explanations. I care for the compression part a lot because I spent quite some time to = write a reasonable efficient compression algorithm that takes both the=20 split into address blocks and the TLVs into account. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060302050101060707010204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNDQ5MDJaMCMGCSqGSIb3DQEJBDEWBBREvXRJnfJgMCajXdM0Cvz5zGuiOjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAPnU8RnS1Ujs7QZzgN5YcUlxm2rShQfAii22NOP2vVdi5 xgcrEyhTgBdHA7XD1fCuFD446EiHfhe1lhsMHxO1pSOTRjU2yaB/DcQk1siRm/sccSDTiChn 8ujvA+toU0yW7RS1EMjmAR5YJccf6ErQ1eIdjQPRBK+aT7nbGa3EzPr1KgCGk4tKEu9sIhqC YW17g+NSl45NFT8dXScqvW/oQAQmtQc500wmXcDK/JoZvbDQi5gdfhv55fO1DfmwoHSCOeuh 5X+QSWUpnD8bswInfFI24b57Zb0JTLSC+zMATNoP49ChMxN42nbhnjzLYoN9Yayh0kAKXQnT mx+eHxoP4wAAAAAAAA== --------------ms060302050101060707010204-- From shares@ndzh.com Mon Jan 14 06:51:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C5821F8953 for ; Mon, 14 Jan 2013 06:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.77 X-Spam-Level: X-Spam-Status: No, score=0.77 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unIagV11+YMY for ; Mon, 14 Jan 2013 06:51:24 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6690421F844C for ; Mon, 14 Jan 2013 06:51:24 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" References: <002b01cdf219$87895140$969bf3c0$@ndzh.com> <50F3B793.40801@fkie.fraunhofer.de> <012a01cdf264$3f095500$bd1bff00$@ndzh.com> <50F418E7.2080002@fkie.fraunhofer.de> In-Reply-To: <50F418E7.2080002@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:51:21 -0500 Message-ID: <015a01cdf266$9e35bbc0$daa13340$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFs1WOqnX2Qr09soDk5w0IQVsDbHgHdC4B7AXGQQGEBRmsbO5jmeTcg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Technical issue 3: default route (Route.pfxlen) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:51:25 -0000 Henning: I agree you want to do the insertion of externals into a reactive = protocol carefully. Having built BGP-3, I tend to agree with you from the protocol coding viewpoint that 0/0 as a unique case is not a good idea. =20 However, there are many places in the Internet operationally which use a default-free zone. =20 Are there operational issues that would lead us to just the 0/0 prefix? I've not seen them listed on the mail list.=20 Sue=20 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: Monday, January 14, 2013 9:41 AM To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Technical issue 3: default route (Route.pfxlen) On 01/14/2013 03:34 PM, Susan Hares wrote: > Henning: > > Implementing insertion of external routes (any prefix) is a well-known case > from ISIS, OSPF, or OLSR. Yes. > Load balancing in a reactive protocols needs metric passed to measure = the > distance to the gateway. I agree that you can do this in a reactive > protocol, but the design needs to be carefully done. What I think you = are > saying, is that this part is being handed off to a reactive protocol > addition at this point. > > Did I understand correctly? I say we should do it right (allow any kind of prefix, maybe with some=20 necessary administrative rules) or postpone it to an extension draft. Building a special case for a single internet gateway (and no other=20 prefixes) sounds like a bad idea. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From shares@ndzh.com Mon Jan 14 06:58:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1169521F8799 for ; Mon, 14 Jan 2013 06:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UliEZsktf1Bg for ; Mon, 14 Jan 2013 06:58:11 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2921F8790 for ; Mon, 14 Jan 2013 06:58:10 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> In-Reply-To: <50F41A84.1080904@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:58:02 -0500 Message-ID: <016101cdf267$8e973580$abc5a080$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDZi1dpew Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:58:13 -0000 Henning: The text might be clearer... but before we hack the text let's go = through "the rest of the story". > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The = case is false.=20 How does the LOADng go on to deal with the detection of the wrap that = caused a back packet to be rotting around in the network?=20 What does the receiver do to decide things which packet is bad? The originator thinks he's sending a perfectly valid packet. The junk = packet has an aligning sequence number.=20 Thanks,=20 Sue=20 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: Monday, January 14, 2013 9:48 AM To: Susan Hares Cc: manet@ietf.org; Ulrich Herberg Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) Sorry for not the bad answer to your first mail. See explanation = below... On 01/14/2013 03:19 PM, Susan Hares wrote: > Henning: > > Thank you for the quick response. Below I have the text sections from > > http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt > > How should I interpret this text? Your comment is > > -1 (0xFFFF), 0, 1 > > How does it work? > > Let us assume S1 rotates through MAX_VALUE > (0xFFFF, 0, 1) , and S2 stays at 0xCFFF. > > The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF > Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF > S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 > > Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore = s1 is > S2 > Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > 0x3FFF > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case = follows >> The sequence number S1 is said to be "greater than" (denoted '>') >> the sequence number S2 if: >> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > = MAXVALUE/2 If this formula is "true", S1 is considered larger than S2. If this formula is "false", S1 is considered to be smaller than S2. Its a single boolean formula, no "two cases". @Ulrich Herberg: maybe the formula could be presented like this to make it more clear? (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE/2) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From shares@ndzh.com Mon Jan 14 06:59:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7FA21F8953 for ; Mon, 14 Jan 2013 06:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.746 X-Spam-Level: X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3wsBwORN4xv for ; Mon, 14 Jan 2013 06:59:03 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA521F8864 for ; Mon, 14 Jan 2013 06:59:03 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> <012801cdf263$14855960$3d900c20$@ndzh.com> <50F417E4.8070304@fkie.fraunhofer.de> In-Reply-To: <50F417E4.8070304@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 09:59:00 -0500 Message-ID: <016c01cdf267$aff6e900$0fe4bb00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLNxnmL6cVAglJr/WkVENy2ida7LwH+PYT4Aw9Wjq8BafpM+5YVgfug Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:59:04 -0000 Henning: Hmm.... That's an interesting viewpoint. Let me check with my friends = in the security directorate and the KARP texts - maybe I misunderstood how = the KARP mandates were worded.=20 Draft- -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: Monday, January 14, 2013 9:36 AM To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM On 01/14/2013 03:26 PM, Susan Hares wrote: > Henning: > > Again, thank you for aiding my understanding. > > Do I understand from this message that RFC5444 should be the protocol > running GTSM? Yes, I think GTSM is a security consideration (and option) for RFC5444. So AODVv2 could suggest using it for RFC5444, but I don't think its the=20 place to mandate its usage. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From yi.jiazi@gmail.com Mon Jan 14 07:07:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF83C21F8935 for ; Mon, 14 Jan 2013 07:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=1.621, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdtLekaMPd64 for ; Mon, 14 Jan 2013 07:07:21 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4DF21F88CA for ; Mon, 14 Jan 2013 07:07:20 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fq12so3885525lab.25 for ; Mon, 14 Jan 2013 07:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=OAuKvV2zzzRrmhisBkxGg1KbuhlhYtIW9CMYtfi3f5Q=; b=Gg5NSWGUc6j+AMCzBNroRh9C89pp64skAXSlr9jf2yz+T0brpt2Gwkq4tnIKlSRmgv uiHE7I0Um5O2ZBx3OfpM+f4yKExe2fD4tvENa2X7Dx4XMtUPzHCI+XePh3v8lkegUbEZ hq5MLFQB7LfmJ1YovrVACmRX/kti7G8cyB+YuVZf3Q+S0JzxZcnEYL4sUOOxud8UZfJw 6UyNsW2a5eNc7l+8ClIVpLQzFmnlVEkS8zjVPWa8q5VjG5SEdS6sQOCmSNYTx/yWqOgX nFKj8HVIzVuEjxDJQmCAsXAIFVLp9bGnQxkFw7SLNmvNbJXA0iLbxzbhSfPXl8MM7IRA 6SaQ== X-Received: by 10.112.102.5 with SMTP id fk5mr35494815lbb.31.1358176039447; Mon, 14 Jan 2013 07:07:19 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id hm5sm5446830lab.6.2013.01.14.07.07.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 07:07:18 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <016101cdf267$8e973580$abc5a080$@ndzh.com> Date: Mon, 14 Jan 2013 16:07:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:07:22 -0000 Hi,=20 I might miss something.=20 in your step 4 (case 4?), it's just S1=3DS2, i.e. the same sequence = number. Then the receiver will take it as the same message.=20 You mean the sequence number runs so fast, and reaches the same value = again? With 16 bits of sequence number of rfc5444, this is not likely to = happen. Am I wrong? @Henning:=20 yes, we can consider changing the formula as you suggested to make it = clearer.=20 best Jiazi On Jan 14, 2013, at 3:58 PM, "Susan Hares" wrote: > Henning: >=20 > The text might be clearer... but before we hack the text let's go = through > "the rest of the story". >=20 >> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The = case is false.=20 >=20 > How does the LOADng go on to deal with the detection of the wrap that = caused > a back packet to be rotting around in the network?=20 >=20 > What does the receiver do to decide things which packet is bad? The > originator thinks he's sending a perfectly valid packet. The junk = packet > has an aligning sequence number.=20 >=20 > Thanks,=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 > Sent: Monday, January 14, 2013 9:48 AM > To: Susan Hares > Cc: manet@ietf.org; Ulrich Herberg > Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers > (warning long post) >=20 > Sorry for not the bad answer to your first mail. See explanation = below... >=20 > On 01/14/2013 03:19 PM, Susan Hares wrote: >> Henning: >>=20 >> Thank you for the quick response. Below I have the text sections = from >>=20 >> http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt >>=20 >> How should I interpret this text? Your comment is >>=20 >> -1 (0xFFFF), 0, 1 >>=20 >> How does it work? >>=20 >> Let us assume S1 rotates through MAX_VALUE >> (0xFFFF, 0, 1) , and S2 stays at 0xCFFF. >>=20 >> The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF >> Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF >> S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 >>=20 >> Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore = s1 is > S2 >> Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > = 0x3FFF >> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no = case follows >=20 >>> The sequence number S1 is said to be "greater than" (denoted '>') >>> the sequence number S2 if: >=20 >>> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > = MAXVALUE/2 >=20 > If this formula is "true", S1 is considered larger than S2. > If this formula is "false", S1 is considered to be smaller than S2. >=20 > Its a single boolean formula, no "two cases". >=20 > @Ulrich Herberg: >=20 > maybe the formula could be presented like this to make it more clear? >=20 > (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 >=20 > OR S1 < S2 AND S2 - S1 > MAXVALUE/2) >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Mon Jan 14 07:09:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00721F88CA for ; Mon, 14 Jan 2013 07:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlo1PLCVvO+W for ; Mon, 14 Jan 2013 07:09:49 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9121F88AE for ; Mon, 14 Jan 2013 07:09:49 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TulfY-0007pD-Lb; Mon, 14 Jan 2013 16:09:48 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TulfY-00065Q-It; Mon, 14 Jan 2013 16:09:48 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 16:09:48 +0100 Message-ID: <50F41FB6.3000701@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 16:09:42 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Susan Hares References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> In-Reply-To: <016101cdf267$8e973580$abc5a080$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070402010009030605070904" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16486/Mon Jan 14 12:43:08 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:09:50 -0000 --------------ms070402010009030605070904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/14/2013 03:58 PM, Susan Hares wrote: > Henning: > > The text might be clearer... but before we hack the text let's go throu= gh > "the rest of the story". > >> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The c= ase is false. If you use the "greater than" relation for the question "new" > "old" you will get the answer false... so you drop the message because you=20 want the new packet greater (and not just equal) to the one you already=20 know. But maybe I am misunderstanding your argument? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070402010009030605070904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTQxNTA5NDZaMCMGCSqGSIb3DQEJBDEWBBTYsuJAkmwYOLrjSCq8DeKTqzwTzzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAvQXfPsM6ewKIN/QRSRV+qVpgYZ1tsnIqV0GaBij6qr34 xxzvzK/YkJ1E9OISbKSyYs4W8uwED9UXG0Sms19aw4rr782T3b3znafUOyEeHNr4Cr0kncTY f18gSNEFyqEsxgaIrLRsARjzmWMBot19ct20h30DNxfKRaUjo3TEDOMQ7RcgKhT40ddLuYMK gjg1SuYvPZn0ll3lgSSTHs6m/TfOQ0F2jygjocrpbeQoaBhCDz+Z0bZfvI2B6smLwxWycYJm tERq8N2b5D8gZ0pIt43CkkGfObXNgvV2bhRF5/JoGPK6m3MNblHga69kEMnabp7e1YwJ68k0 9HzTGtR4FQAAAAAAAA== --------------ms070402010009030605070904-- From shares@ndzh.com Mon Jan 14 07:16:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5121F895F for ; Mon, 14 Jan 2013 07:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKEwPcF79F7W for ; Mon, 14 Jan 2013 07:16:55 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04221F88E2 for ; Mon, 14 Jan 2013 07:16:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Jiazi Yi'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> In-Reply-To: Date: Mon, 14 Jan 2013 10:16:51 -0500 Message-ID: <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfOYlMLEcA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:16:56 -0000 Jiazi: That's the issue, in step 4 the receiver will take it as the same = message.=20 For details see my case below - broken implementation sending original received packet or a newly received packet with fix 0xCFFF as sequence number.=20 Sue=20 -----Original Message----- From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Yi Sent: Monday, January 14, 2013 10:07 AM To: Susan Hares Cc: 'Henning Rogge'; manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) Hi,=20 I might miss something.=20 in your step 4 (case 4?), it's just S1=3DS2, i.e. the same sequence = number. Then the receiver will take it as the same message.=20 You mean the sequence number runs so fast, and reaches the same value = again? With 16 bits of sequence number of rfc5444, this is not likely to = happen. Am I wrong? @Henning:=20 yes, we can consider changing the formula as you suggested to make it clearer.=20 best Jiazi On Jan 14, 2013, at 3:58 PM, "Susan Hares" wrote: > Henning: >=20 > The text might be clearer... but before we hack the text let's go=20 > through "the rest of the story". >=20 >> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The = case is false. >=20 > How does the LOADng go on to deal with the detection of the wrap that=20 > caused a back packet to be rotting around in the network? >=20 > What does the receiver do to decide things which packet is bad? The=20 > originator thinks he's sending a perfectly valid packet. The junk=20 > packet has an aligning sequence number. >=20 > Thanks, >=20 > Sue >=20 > -----Original Message----- > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > Sent: Monday, January 14, 2013 9:48 AM > To: Susan Hares > Cc: manet@ietf.org; Ulrich Herberg > Subject: Re: [manet] Hares technical question 1: Design of sequence=20 > numbers (warning long post) >=20 > Sorry for not the bad answer to your first mail. See explanation = below... >=20 > On 01/14/2013 03:19 PM, Susan Hares wrote: >> Henning: >>=20 >> Thank you for the quick response. Below I have the text sections=20 >> from >>=20 >> http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt >>=20 >> How should I interpret this text? Your comment is >>=20 >> -1 (0xFFFF), 0, 1 >>=20 >> How does it work? >>=20 >> Let us assume S1 rotates through MAX_VALUE (0xFFFF, 0, 1) , and S2=20 >> stays at 0xCFFF. >>=20 >> The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF = Step=20 >> 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF >> S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 >>=20 >> Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore = s1 is=20 >> > S2 Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > = 0x3FFF=20 >> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no = case=20 >> follows >=20 >>> The sequence number S1 is said to be "greater than" (denoted '>')=20 >>> the sequence number S2 if: >=20 >>> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 >=20 >>> MAXVALUE/2 >=20 > If this formula is "true", S1 is considered larger than S2. > If this formula is "false", S1 is considered to be smaller than S2. >=20 > Its a single boolean formula, no "two cases". >=20 > @Ulrich Herberg: >=20 > maybe the formula could be presented like this to make it more clear? >=20 > (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 >=20 > OR S1 < S2 AND S2 - S1 > MAXVALUE/2) >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 > Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 > Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20 > Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From shares@ndzh.com Mon Jan 14 07:21:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C421F8AF8 for ; Mon, 14 Jan 2013 07:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.726 X-Spam-Level: X-Spam-Status: No, score=0.726 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0nAOgrluTco for ; Mon, 14 Jan 2013 07:21:21 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27E21F8AD8 for ; Mon, 14 Jan 2013 07:21:18 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=206.191.100.2; From: "Susan Hares" To: "'Henning Rogge'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <50F41FB6.3000701@fkie.fraunhofer.de> In-Reply-To: <50F41FB6.3000701@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 10:21:12 -0500 Message-ID: <017e01cdf26a$ca2c04b0$5e840e10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWAl1/tuKYlpuWMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:21:21 -0000 Henning: You are saying the receiver test is: Is the new > old=20 [via test we've been discussion]=20 if true, update packet=20 if false, toss packet.=20 Since, the S1=3DS2 - creates a false, then you toss the packet.=20 Then the behavior depends on whether the bad packet reaches the node or = the new good packet from the real originator. The bad packet is the one = that was old and now you hit the reused sequence number.=20 Thank you for your quick response,=20 Sue=20 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: Monday, January 14, 2013 10:10 AM To: Susan Hares Cc: manet@ietf.org; 'Ulrich Herberg' Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) On 01/14/2013 03:58 PM, Susan Hares wrote: > Henning: > > The text might be clearer... but before we hack the text let's go = through > "the rest of the story". > >> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The = case is false. If you use the "greater than" relation for the question "new" > "old" you will get the answer false... so you drop the message because you=20 want the new packet greater (and not just equal) to the one you already=20 know. But maybe I am misunderstanding your argument? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From yi.jiazi@gmail.com Mon Jan 14 07:51:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB58B21F8925 for ; Mon, 14 Jan 2013 07:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLUQSDk9RqDr for ; Mon, 14 Jan 2013 07:51:55 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5421F8953 for ; Mon, 14 Jan 2013 07:51:54 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id je9so2073720bkc.27 for ; Mon, 14 Jan 2013 07:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=hblNPIGyNNdpNDsN39xq7H8JTrbIiSNM6L+/0gjT71s=; b=aFVvKEy46ZvNDdNytbJvIfngx39yU+ctfw2dak0zvyRSJHj4vjKycGQNUCrB2KZCRW 3b2HL091LCEDINS/qffIxuy9E1sIsY0hgg+H5XPBy23T65Clij3xedJvLw0DSdojAy3B HJ+bD7q4xfzp224D4k2rrstn6nbmxVXnfTO8Pg5JZNaK6GcKkLhU4TP2SEwOkRgycNGM Gyo1Gd/O6dUxdFrz4HK00un4+vaxQriBxdx1jTfaJ2bMYRvR0N+fawxMAeteNN8ihCxS t6ZWQUo/TrKneb4fv7wzINq+FfrRvcrCu9uHcsXPzhfaYUIFe34pKH4WKeq1TskJLodi osAQ== X-Received: by 10.204.5.69 with SMTP id 5mr38870106bku.26.1358178713933; Mon, 14 Jan 2013 07:51:53 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id l17sm10203906bkw.12.2013.01.14.07.51.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 07:51:53 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> Date: Mon, 14 Jan 2013 16:51:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:51:57 -0000 Hi,=20 For LOADng, the sequence number MUST NOT be changed by intermediate = routers. In the vulnerability analysis of LOADng, changing sequence = number can result in a pre-play attack.=20 As a basic mechanism of LOADng, if a implementation doesn't do sequence = number properly, and does something that the specification explicitly = prohibit from doing, it should be regarded as a malicious behavior (in = security consideration, indicate as "A LOADng Router forwards altered = control messages").=20 LOADng currently couldn't distinguish between two different message with = the same sequence number and originator address. I'm wondering that = other MANET protocols like OLSR, AODV, SMF (identification-based = duplicate detection) won't be able to detect that either.=20 This also brings me the question how further we should go in a protocol = specification, to prevent "broken implementation"? best Jiazi On Jan 14, 2013, at 4:16 PM, "Susan Hares" wrote: > Jiazi: >=20 > That's the issue, in step 4 the receiver will take it as the same = message.=20 >=20 > For details see my case below - broken implementation sending original > received packet or a newly received packet with fix 0xCFFF as sequence > number.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Yi > Sent: Monday, January 14, 2013 10:07 AM > To: Susan Hares > Cc: 'Henning Rogge'; manet@ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers > (warning long post) >=20 > Hi,=20 >=20 > I might miss something.=20 >=20 > in your step 4 (case 4?), it's just S1=3DS2, i.e. the same sequence = number. > Then the receiver will take it as the same message.=20 >=20 > You mean the sequence number runs so fast, and reaches the same value = again? > With 16 bits of sequence number of rfc5444, this is not likely to = happen. Am > I wrong? >=20 > @Henning:=20 >=20 > yes, we can consider changing the formula as you suggested to make it > clearer.=20 >=20 > best >=20 > Jiazi >=20 >=20 >=20 > On Jan 14, 2013, at 3:58 PM, "Susan Hares" wrote: >=20 >> Henning: >>=20 >> The text might be clearer... but before we hack the text let's go=20 >> through "the rest of the story". >>=20 >>> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The = case is false. >=20 >>=20 >> How does the LOADng go on to deal with the detection of the wrap that=20= >> caused a back packet to be rotting around in the network? >>=20 >> What does the receiver do to decide things which packet is bad? The=20= >> originator thinks he's sending a perfectly valid packet. The junk=20 >> packet has an aligning sequence number. >>=20 >> Thanks, >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >> Sent: Monday, January 14, 2013 9:48 AM >> To: Susan Hares >> Cc: manet@ietf.org; Ulrich Herberg >> Subject: Re: [manet] Hares technical question 1: Design of sequence=20= >> numbers (warning long post) >>=20 >> Sorry for not the bad answer to your first mail. See explanation = below... >>=20 >> On 01/14/2013 03:19 PM, Susan Hares wrote: >>> Henning: >>>=20 >>> Thank you for the quick response. Below I have the text sections=20 >>> from >>>=20 >>> http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt >>>=20 >>> How should I interpret this text? Your comment is >>>=20 >>> -1 (0xFFFF), 0, 1 >>>=20 >>> How does it work? >>>=20 >>> Let us assume S1 rotates through MAX_VALUE (0xFFFF, 0, 1) , and S2=20= >>> stays at 0xCFFF. >>>=20 >>> The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF = Step=20 >>> 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF >>> S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 >>>=20 >>> Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, = therefore s1 is=20 >>>> S2 Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > = 0x3FFF=20 >>> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no = case=20 >>> follows >>=20 >>>> The sequence number S1 is said to be "greater than" (denoted '>')=20= >>>> the sequence number S2 if: >>=20 >>>> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 >=20 >>>> MAXVALUE/2 >>=20 >> If this formula is "true", S1 is considered larger than S2. >> If this formula is "false", S1 is considered to be smaller than S2. >>=20 >> Its a single boolean formula, no "two cases". >>=20 >> @Ulrich Herberg: >>=20 >> maybe the formula could be presented like this to make it more clear? >>=20 >> (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 >>=20 >> OR S1 < S2 AND S2 - S1 > MAXVALUE/2) >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20= >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From shares@ndzh.com Mon Jan 14 10:05:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF3C21F892C for ; Mon, 14 Jan 2013 10:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.717 X-Spam-Level: X-Spam-Status: No, score=0.717 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xSmcBH56YNL for ; Mon, 14 Jan 2013 10:05:46 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B0B6721F84F4 for ; Mon, 14 Jan 2013 10:05:44 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=209.82.80.110; From: "Susan Hares" To: "'Jiazi Yi'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> In-Reply-To: <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> Date: Mon, 14 Jan 2013 13:05:41 -0500 Message-ID: <001601cdf281$c429a920$4c7cfb60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zmG+eRuA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:05:52 -0000 Jiazi: Please note that I am not suggesting changes to LOADng at this point. I = am simply attempting to understand. =20 Some people make the wrap number (0, 0xFFFF) as a clear indication that something has wrapped. It is just one method, and this is another. = I'm trying to understand the pros/cons of each method.=20 How many different implementations (that is uniquely coded from scratch) coded this sequence number rotation? How did the debugging go?=20 This methodology is new to me ... so I'm just digging deeper to = understand it. =20 Sue=20 -----Original Message----- From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Yi Sent: Monday, January 14, 2013 10:52 AM To: Susan Hares Cc: 'Henning Rogge'; manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) Hi,=20 For LOADng, the sequence number MUST NOT be changed by intermediate = routers. In the vulnerability analysis of LOADng, changing sequence number can = result in a pre-play attack.=20 As a basic mechanism of LOADng, if a implementation doesn't do sequence number properly, and does something that the specification explicitly prohibit from doing, it should be regarded as a malicious behavior (in security consideration, indicate as "A LOADng Router forwards altered control messages").=20 LOADng currently couldn't distinguish between two different message with = the same sequence number and originator address. I'm wondering that other = MANET protocols like OLSR, AODV, SMF (identification-based duplicate = detection) won't be able to detect that either.=20 This also brings me the question how further we should go in a protocol specification, to prevent "broken implementation"? best Jiazi On Jan 14, 2013, at 4:16 PM, "Susan Hares" wrote: > Jiazi: >=20 > That's the issue, in step 4 the receiver will take it as the same = message. >=20 > For details see my case below - broken implementation sending original = > received packet or a newly received packet with fix 0xCFFF as sequence = > number. >=20 > Sue >=20 > -----Original Message----- > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Yi > Sent: Monday, January 14, 2013 10:07 AM > To: Susan Hares > Cc: 'Henning Rogge'; manet@ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence=20 > numbers (warning long post) >=20 > Hi, >=20 > I might miss something.=20 >=20 > in your step 4 (case 4?), it's just S1=3DS2, i.e. the same sequence = number. > Then the receiver will take it as the same message.=20 >=20 > You mean the sequence number runs so fast, and reaches the same value again? > With 16 bits of sequence number of rfc5444, this is not likely to=20 > happen. Am I wrong? >=20 > @Henning:=20 >=20 > yes, we can consider changing the formula as you suggested to make it=20 > clearer. >=20 > best >=20 > Jiazi >=20 >=20 >=20 > On Jan 14, 2013, at 3:58 PM, "Susan Hares" wrote: >=20 >> Henning: >>=20 >> The text might be clearer... but before we hack the text let's go=20 >> through "the rest of the story". >>=20 >>> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> The = case is false. >=20 >>=20 >> How does the LOADng go on to deal with the detection of the wrap that = >> caused a back packet to be rotting around in the network? >>=20 >> What does the receiver do to decide things which packet is bad? The=20 >> originator thinks he's sending a perfectly valid packet. The junk=20 >> packet has an aligning sequence number. >>=20 >> Thanks, >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >> Sent: Monday, January 14, 2013 9:48 AM >> To: Susan Hares >> Cc: manet@ietf.org; Ulrich Herberg >> Subject: Re: [manet] Hares technical question 1: Design of sequence=20 >> numbers (warning long post) >>=20 >> Sorry for not the bad answer to your first mail. See explanation = below... >>=20 >> On 01/14/2013 03:19 PM, Susan Hares wrote: >>> Henning: >>>=20 >>> Thank you for the quick response. Below I have the text sections=20 >>> from >>>=20 >>> http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt >>>=20 >>> How should I interpret this text? Your comment is >>>=20 >>> -1 (0xFFFF), 0, 1 >>>=20 >>> How does it work? >>>=20 >>> Let us assume S1 rotates through MAX_VALUE (0xFFFF, 0, 1) , and S2=20 >>> stays at 0xCFFF. >>>=20 >>> The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF = Step=20 >>> 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF >>> S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 >>>=20 >>> Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, = therefore s1=20 >>> is >>>> S2 Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > = 0x3FFF >>> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no = case=20 >>> follows >>=20 >>>> The sequence number S1 is said to be "greater than" (denoted '>')=20 >>>> the sequence number S2 if: >>=20 >>>> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > >>>> MAXVALUE/2 >>=20 >> If this formula is "true", S1 is considered larger than S2. >> If this formula is "false", S1 is considered to be smaller than S2. >>=20 >> Its a single boolean formula, no "two cases". >>=20 >> @Ulrich Herberg: >>=20 >> maybe the formula could be presented like this to make it more clear? >>=20 >> (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 >>=20 >> OR S1 < S2 AND S2 - S1 > MAXVALUE/2) >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20 >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From hrogge@googlemail.com Mon Jan 14 10:16:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E863A21F8893 for ; Mon, 14 Jan 2013 10:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIFrZTzi-6bg for ; Mon, 14 Jan 2013 10:16:00 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id DCF3C21F888C for ; Mon, 14 Jan 2013 10:15:59 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id gi11so3174730lbb.19 for ; Mon, 14 Jan 2013 10:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZsjOxDpPf0EGp9f6SulgZRPuTqhQJclpO4984khlbCk=; b=S4NyHP4AAceSzs/yLfbHj7VTEqO1EvMMwIBoRQlpJt2uVQOqVaPSG2vtOl71hpua2X qGqEVNgq/sWEU8jQsN+kgR2Fd5teHbVIYsrJgoQN2qpvWnmPpufB0D+iq/KHk6cKs832 tir0R8n3cQnvWrgb+hppfZ2pOlQRgmXfXHUBQc0ehdTLDPIyoV0qh5TXUSzRkR8KFNoE MDG8W8fzbdH9YvDgXtA3Y6IsBve360uNU2LC0T1uUIugIlnwM0vd5PhhLqnX8OPCWSPG l4shIJTXjQrFNdWs5hpwB6bHE72NyPLIZr0QBzBHEwsf4QSIfwWGastvDzDn7y8lH8t1 eYsA== Received: by 10.152.114.42 with SMTP id jd10mr21025067lab.31.1358187358833; Mon, 14 Jan 2013 10:15:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Mon, 14 Jan 2013 10:15:38 -0800 (PST) In-Reply-To: <001601cdf281$c429a920$4c7cfb60$@ndzh.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> From: Henning Rogge Date: Mon, 14 Jan 2013 19:15:38 +0100 Message-ID: To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:16:01 -0000 On Mon, Jan 14, 2013 at 7:05 PM, Susan Hares wrote: > Some people make the wrap number (0, 0xFFFF) as a clear indication that > something has wrapped. It is just one method, and this is another. I'm > trying to understand the pros/cons of each method. What if the message with the "magic number change" gets lost? That is a common thing in wireless networks. > How many different implementations (that is uniquely coded from scratch) > coded this sequence number rotation? I think the olsr.org (OLSRv1) code went through multiple variations of this code, with several people "testing optimizations" when the original RFC didn't worked well. > How did the debugging go? By having hundreds of users with real wifi networks willing to test the new version first? ;) At the moment we have (I think, but I have to check) a standard compliant "greater than" check in the code and some unique duplicate check system based on a 32bit shifting register (for each originator). Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From yi.jiazi@gmail.com Mon Jan 14 10:19:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2BF21F8958 for ; Mon, 14 Jan 2013 10:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po5ukU7nQlIe for ; Mon, 14 Jan 2013 10:19:36 -0800 (PST) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by ietfa.amsl.com (Postfix) with ESMTP id 33A5C21F88D6 for ; Mon, 14 Jan 2013 10:19:35 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id jk13so2137392bkc.32 for ; Mon, 14 Jan 2013 10:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=MkRupj9g+oENrm80kLTV4IjN6UmRsSQNy9I089otLeU=; b=VSnRD7L4OeuARjmk9r0ck2yP96rilVOnFIPlPZ+UAgenE2yJmHsggCDLv5PE0THrO5 WmFS8Mif5KKFn6lY5ICkB3fRdOM6P8A9dHyAzBb5NZM+KTGu2cJChdpYnAXEcv45FVLG B2YoUQgnm4hPD5c/IS9Y4p+mOosZce9/4XHY/noos7RHxlmrgQMaz7EYa9LY5Tl846Gr dFPSaEcmRXWxrntl7Q8YDExSZB/l5ixApEc3DMXcuQl8dShz7JXTosotyrflxNXuupAV VTFpmEsX+n46pmtmSQ8tJoQ5YlqlAp3v5opY7EKNO6M2CLXrLr4Szlem/odVb8QyU08z unAg== X-Received: by 10.204.153.27 with SMTP id i27mr38860375bkw.116.1358187575142; Mon, 14 Jan 2013 10:19:35 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id e22sm10702934bke.14.2013.01.14.10.19.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 10:19:34 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <001601cdf281$c429a920$4c7cfb60$@ndzh.com> Date: Mon, 14 Jan 2013 19:19:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:19:37 -0000 Dear Sue: On Jan 14, 2013, at 7:05 PM, Susan Hares wrote: > Jiazi: >=20 > Please note that I am not suggesting changes to LOADng at this point. = I am > simply attempting to understand. =20 >=20 > Some people make the wrap number (0, 0xFFFF) as a clear indication = that > something has wrapped. It is just one method, and this is another. = I'm > trying to understand the pros/cons of each method.=20 In MANET, this clear "indication" can easily be missed, because some of = the messages can be lost, and some of them are unicast messages only.=20 >=20 > How many different implementations (that is uniquely coded from = scratch) > coded this sequence number rotation? How did the debugging go?=20 For LOADng, which make use of this sequence number rotation, has at = least 4 independent implementations. As far as I can see, I didn't = notice any issue.=20 In the meantime, this rotation is used in since OLSR version 1 (rfc = 3626), so there are must be tens of them. Henning is an expert of this.=20= best Jiazi >=20 > This methodology is new to me ... so I'm just digging deeper to = understand > it. =20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Yi > Sent: Monday, January 14, 2013 10:52 AM > To: Susan Hares > Cc: 'Henning Rogge'; manet@ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers > (warning long post) >=20 > Hi,=20 >=20 > For LOADng, the sequence number MUST NOT be changed by intermediate = routers. > In the vulnerability analysis of LOADng, changing sequence number can = result > in a pre-play attack.=20 >=20 > As a basic mechanism of LOADng, if a implementation doesn't do = sequence > number properly, and does something that the specification explicitly > prohibit from doing, it should be regarded as a malicious behavior (in > security consideration, indicate as "A LOADng Router forwards altered > control messages").=20 >=20 > LOADng currently couldn't distinguish between two different message = with the > same sequence number and originator address. I'm wondering that other = MANET > protocols like OLSR, AODV, SMF (identification-based duplicate = detection) > won't be able to detect that either.=20 >=20 > This also brings me the question how further we should go in a = protocol > specification, to prevent "broken implementation"? >=20 > best >=20 > Jiazi >=20 > On Jan 14, 2013, at 4:16 PM, "Susan Hares" wrote: >=20 >> Jiazi: >>=20 >> That's the issue, in step 4 the receiver will take it as the same = message. >=20 >>=20 >> For details see my case below - broken implementation sending = original=20 >> received packet or a newly received packet with fix 0xCFFF as = sequence=20 >> number. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Yi >> Sent: Monday, January 14, 2013 10:07 AM >> To: Susan Hares >> Cc: 'Henning Rogge'; manet@ietf.org >> Subject: Re: [manet] Hares technical question 1: Design of sequence=20= >> numbers (warning long post) >>=20 >> Hi, >>=20 >> I might miss something.=20 >>=20 >> in your step 4 (case 4?), it's just S1=3DS2, i.e. the same sequence = number. >> Then the receiver will take it as the same message.=20 >>=20 >> You mean the sequence number runs so fast, and reaches the same value > again? >> With 16 bits of sequence number of rfc5444, this is not likely to=20 >> happen. Am I wrong? >>=20 >> @Henning:=20 >>=20 >> yes, we can consider changing the formula as you suggested to make it=20= >> clearer. >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >>=20 >> On Jan 14, 2013, at 3:58 PM, "Susan Hares" wrote: >>=20 >>> Henning: >>>=20 >>> The text might be clearer... but before we hack the text let's go=20 >>> through "the rest of the story". >>>=20 >>>> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 =3D=3D> = The case is > false. >>=20 >>>=20 >>> How does the LOADng go on to deal with the detection of the wrap = that=20 >>> caused a back packet to be rotting around in the network? >>>=20 >>> What does the receiver do to decide things which packet is bad? The=20= >>> originator thinks he's sending a perfectly valid packet. The junk=20= >>> packet has an aligning sequence number. >>>=20 >>> Thanks, >>>=20 >>> Sue >>>=20 >>> -----Original Message----- >>> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >>> Sent: Monday, January 14, 2013 9:48 AM >>> To: Susan Hares >>> Cc: manet@ietf.org; Ulrich Herberg >>> Subject: Re: [manet] Hares technical question 1: Design of sequence=20= >>> numbers (warning long post) >>>=20 >>> Sorry for not the bad answer to your first mail. See explanation = below... >>>=20 >>> On 01/14/2013 03:19 PM, Susan Hares wrote: >>>> Henning: >>>>=20 >>>> Thank you for the quick response. Below I have the text sections=20= >>>> from >>>>=20 >>>> http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt >>>>=20 >>>> How should I interpret this text? Your comment is >>>>=20 >>>> -1 (0xFFFF), 0, 1 >>>>=20 >>>> How does it work? >>>>=20 >>>> Let us assume S1 rotates through MAX_VALUE (0xFFFF, 0, 1) , and S2=20= >>>> stays at 0xCFFF. >>>>=20 >>>> The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF = Step=20 >>>> 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF >>>> S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 >>>>=20 >>>> Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, = therefore s1=20 >>>> is >>>>> S2 Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > = 0x3FFF >>>> Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no = case=20 >>>> follows >>>=20 >>>>> The sequence number S1 is said to be "greater than" (denoted '>')=20= >>>>> the sequence number S2 if: >>>=20 >>>>> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > >>>>> MAXVALUE/2 >>>=20 >>> If this formula is "true", S1 is considered larger than S2. >>> If this formula is "false", S1 is considered to be smaller than S2. >>>=20 >>> Its a single boolean formula, no "two cases". >>>=20 >>> @Ulrich Herberg: >>>=20 >>> maybe the formula could be presented like this to make it more = clear? >>>=20 >>> (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 >>>=20 >>> OR S1 < S2 AND S2 - S1 > MAXVALUE/2) >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20= >>> Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >=20 >=20 From abdussalambaryun@gmail.com Mon Jan 14 10:41:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF70621F888E for ; Mon, 14 Jan 2013 10:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6vauHhVj13b for ; Mon, 14 Jan 2013 10:41:40 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id ACF2C21F885E for ; Mon, 14 Jan 2013 10:41:40 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so3943670vcb.29 for ; Mon, 14 Jan 2013 10:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KJjE8JycSV9hzjPAEtod5eqRE2neMrzpCQY77P3KGk0=; b=brDCjzszAIkaW3jw3eHVlwoWl9tzuJ+1R1dvxdR9w4hWvrfo4gH2BhO1X44jOwjqrp cCgrwMB/qOVuGVMXV6GDhv2DH5LOJV6ViJLAar/lQx50ZPm/3TNaSxNjvk/B84bo9j9v zT04kVN7jtBsRT+eGtq4Rj2pcgoLlCqURBtsATLM+OAqaycYl0aKXo87aaZhArrrpUpH NKiFcUNZa92HGRbfRKmA3fqHWRtiifM3qc7rKQTnAJ6jfUmGXElZ1T551jA0VEa5iXlf JBA2HE0sqmkMqcmI6GjXpZZUaZN67YVOig0mpxIeAfDSh2IbTL3nKAuAd5f4BOMR/7JE xK2Q== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr88731377vdc.125.1358188900081; Mon, 14 Jan 2013 10:41:40 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 14 Jan 2013 10:41:39 -0800 (PST) In-Reply-To: <001601cdf281$c429a920$4c7cfb60$@ndzh.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> Date: Mon, 14 Jan 2013 19:41:39 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:41:42 -0000 On 1/14/13, Susan Hares wrote: > Some people make the wrap number (0, 0xFFFF) as a clear indication that > something has wrapped. It is just one method, and this is another. I'm > trying to understand the pros/cons of each method. > it is a simple method without indication and don't think there maybe a disadvantage, do you see one? > How many different implementations (that is uniquely coded from scratch) > coded this sequence number rotation? How did the debugging go? I did not check it but don't see any problem yet, AB From adrian@olddog.co.uk Mon Jan 14 10:41:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227C821F88C7 for ; Mon, 14 Jan 2013 10:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj0NA14A3MSC for ; Mon, 14 Jan 2013 10:41:55 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 23E8B21F88C8 for ; Mon, 14 Jan 2013 10:41:54 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0EIfprt008036; Mon, 14 Jan 2013 18:41:51 GMT Received: from 950129200 (089144192180.atnat0001.highway.a1.net [89.144.192.180]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0EIfjPg007987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jan 2013 18:41:48 GMT From: "Adrian Farrel" To: Date: Mon, 14 Jan 2013 18:41:44 -0000 Message-ID: <024001cdf286$d01a81f0$704f85d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yhseRGvQxMEXLRFaH+HpxRo5JTg== Content-Language: en-gb Cc: manet-chairs@tools.ietf.org Subject: [manet] Decision on Reactive Protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:41:56 -0000 Hello MANET working group. Thank you to all the people (23) who expressed an opinion on or off the list in answer to my three questions. Thank you, too, to those of you who felt the need to give me more background on your thinking. It is overwhelmingly clear that the WG wants to find a way to pursue a Reactive Protocol. Very few of you said that removing Reactive from the charter was something they would be happy with. So we will try to find a way to struggle on with the charter we have. A significant minority (roughly one in three), said they would be willing to progress two Experimental I-Ds in parallel within the working group. However, many of these people expressed reservations, preferences for variations, or noted that this was a last resort in their view. Thus, although this is clearly the easiest option to the production of an RFC describing a Reactive protocol, I am also rejecting this option. Not an insignificant factor for me was the observation that MANET has already produced an Experimental Reactive protocol and made the decision to move on with a Standards Track protocol. OK, so that means that we will work on a single Standards Track reactive protocol, and I (oh, lucky me!) get to choose which document will form the basis of this work. I feel rather like the vicar announcing the results of the beautiful baby competition - I know that the mothers of the babies that don't win will gouge my eyes out later in the cream tea tent. We will run with the current working group I-D (draft-ietf-manet-dymo), but with several significant caveats: - The document will be renamed draft-ietf-manet-aodv-v2-00.txt - The chairs will announce a new editor team - I expect the new document to be rewritten/restructured as necessary for readability and utility according to the demands of the WG - I expect all people who provide text to be suitably credited - Acknowledgments section for small pieces of text - Contributing Author section for larger pieces of text - I expect ideas and text to be freely taken from draft-clausen-loadng with appropriate credit to the authors - I expect the editors of the new draft to bow to WG consensus at all times (even when they personally think the idea is wrong) - I would not be surprised if the content of the document changed radically over the next few revisions To achieve all this, the editor team will need to do more than hold the pen. I expect them to use the issue tracker system and to patiently work through the issues bringing them up for debate in small numbers so that everyone can participate in the discussion without losing track of the issues. For the editors, this will be as much a management challenge as a protocol design task. I note that, when I asked my question, I made it clear that if this option was selected I would expect the whole working group to pull behind the single draft. That does not prevent anyone from raising their concerns about the technical direction and from suggesting alternative mechanisms and text. But it does require that everyone gets behind the consensus when it emerges or is called, and it assumes that no-one will be disruptive to the working group process in producing the Standards Track document. I know there will be a huge temptation to debate this decision, express dissatisfaction/disappointment, or raise new points that I might not have considered. However, the decision is made and I hope the WG will now buckle down to the difficult job of pursuing the technical work using the normal tools of IETF debate and documentation. Please be aware that this is not the first time in the history of the IETF that a choice between documents has been necessary where no consensus could be found. In one case a coin was tossed to make the choice! AFAIK, in every case the working group quickly got behind the decision and went ahead to make a high-quality protocol specification. Thank you all for your patience during this decision process. As the chairs and I have all agreed, we (the three of us - and our predecessors) should have stepped in and made decisions sooner. We are where we are, and I hope we can now move forward. Please look out for a further email from the chairs announcing the editorial team. Adrian From abdussalambaryun@gmail.com Mon Jan 14 10:44:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31EC21F87A6 for ; Mon, 14 Jan 2013 10:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNHDJHGqqw+E for ; Mon, 14 Jan 2013 10:44:53 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id EC46B21F85CB for ; Mon, 14 Jan 2013 10:44:52 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so3821353vbb.16 for ; Mon, 14 Jan 2013 10:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=518XCSYvEL0iobNJeRJvaNz4z1+D4aVWySnCPD1Dn2k=; b=tdQEST/eNHeZ2lQezu5mUGuVFDB6VXyZbItP09dF984jjLtO8uNrcZgwYsaOYEWIkz VwkSZaHbWnitNdokSFFj6rnSnNlcSkBvmHksyBmDKVR7CmHvd9oggng/hxNke5YqWj4K CQ3fwXcZghFN8aZRL7ZgwQLy/K0H6CNVTpOnjNMyKQ88C16ID0FkuiXitWkPAU0Mk9hp aqbY6V9i//P4qTVcezRbrmIGx5G7sJp11RJJ+DMruMQs8kFaHtqQSmoPwbgKvAh3hLl3 piiD36TerE8FJ1ODnbuqD5T0t0wmVm5XaUQo30g3p42pY3xDXG3vXohPGb1jqB3Vr++1 Ox+A== MIME-Version: 1.0 Received: by 10.220.8.18 with SMTP id f18mr100966559vcf.14.1358189085161; Mon, 14 Jan 2013 10:44:45 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 14 Jan 2013 10:44:45 -0800 (PST) In-Reply-To: <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> Date: Mon, 14 Jan 2013 19:44:45 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:44:53 -0000 On 1/14/13, Jiazi Yi wrote: > For LOADng, which make use of this sequence number rotation, has at least 4 > independent implementations. As far as I can see, I didn't notice any issue. > Do you mean four different implementation or independent implementation. I understand the independent cannot work together (not interoperable), or am I wrong, AB From abdussalambaryun@gmail.com Mon Jan 14 11:03:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11AF21F87D7 for ; Mon, 14 Jan 2013 11:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C6fagvOMExx for ; Mon, 14 Jan 2013 11:03:31 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC921F87F9 for ; Mon, 14 Jan 2013 11:03:31 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so3943348vbb.10 for ; Mon, 14 Jan 2013 11:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GRlebQHk9EdJS5GGLTsv5jKldBCpp2OxKVcQxhFq0Gw=; b=qRiU+mCL5yYZxIJI5rkQXcoGsGJ6jEv72+nJ5mVRasWXFGT0WdOXcRcthuph4gvGs4 dbXcRgZextM4cWCS52/PVs5mmc0+Kq92Rd8DWzs3wbx8Kc+ooxt+SNxnkJIsdn1wD2O0 TGh8fs+Du+YHb+UHvuWqS0dKdNbGi5E8tpDkRTwZ6uiwlS/LkI4n+D5l0dn9Y7mbfLhR uTnO3bN4kg6rgzEuhlJeVDdJqzG/i5Jf8N6vVmLRgKt6PhwQ+3Rs8BVdGFJwYwr6YsFl GsaoZVOCmzQHeZNKN1b4AgmtqkvRvoqm8aGkgGcpN8cQUntEutVLR5bFWPTEOWSwbgy4 /G7A== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr88774330vdu.99.1358190210730; Mon, 14 Jan 2013 11:03:30 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 14 Jan 2013 11:03:30 -0800 (PST) In-Reply-To: <50F3FA50.1070506@fkie.fraunhofer.de> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F3FA50.1070506@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 20:03:30 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:03:33 -0000 Why you think I missed any point, does the RFC5444 explain the point of its TLV which I don't know? AB On 1/14/13, Henning Rogge wrote: > On 01/14/2013 01:17 PM, Abdussalam Baryun wrote: >> On 1/14/13, Henning Rogge wrote: >>> The normal thing for RFC5444 should be that protocols do NOT specify a >>> mandatory order of Addresses or TLVs. >> >> IMO, the RFC5444 states that it is the protocol to define/specify its >> RFC5444 messages, so this makes RFC5444 format general, but if its >> updated to want the MANET routing protocol to follow a general order >> way also, then I think the RFC5444 will be more limiting protocol's >> activity. > > I think you are missing the point of a TLV format. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From abdussalambaryun@gmail.com Mon Jan 14 11:08:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B621F8AC3 for ; Mon, 14 Jan 2013 11:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IftHy2UNuW-O for ; Mon, 14 Jan 2013 11:08:59 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 200AD21F8A05 for ; Mon, 14 Jan 2013 11:08:59 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id fy27so3905906vcb.13 for ; Mon, 14 Jan 2013 11:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bgOyE42/i/MiuedVvVMphbLc2kB1txlboFv3f1NEbWA=; b=ZwEMjCzEG4k0dcWO7eeV09Mtfc7R2lQ5vss8idS5KMtaifHABBS7a9eBUYcxetx+zp xPeOhlL869J4oivkzabFN30+Ub/h81dP4tq0yRmc3OuTRMyOfIHtVPjcRLmlGU6sRpGW ddC8UD0X0ZRQ8TvHnUzcrFvBNW8KIcaQBys9Nxld9hDoM8mnS0X5Z2YrSC3s/M4iWMFr urzRn38Q2+RBdxPBNISCLz9WvjXKlrn9MfOHEydId91wR9sqkfmShwYQw/kiY3JYi21H XqOzv6cespa2EKmJWXoylEKy72IHZN/1M5OXaFV2Um5vxK7mHVI/z1J63ba/wUr5rzc/ Z/fg== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr88794386vdc.125.1358190534234; Mon, 14 Jan 2013 11:08:54 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 14 Jan 2013 11:08:54 -0800 (PST) In-Reply-To: <50F41ADE.1030902@fkie.fraunhofer.de> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <012601cdf262$bdcd2f30$39678d90$@ndzh.com> <50F41795.3030601@fkie.fraunhofer.de> <014201cdf265$a4b70950$ee251bf0$@ndzh.com> <50F41ADE.1030902@fkie.fraunhofer.de> Date: Mon, 14 Jan 2013 20:08:54 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:08:59 -0000 On 1/14/13, Henning Rogge wrote: > I care for the compression part a lot because I spent quite some time to > write a reasonable efficient compression algorithm that takes both the > split into address blocks and the TLVs into account. > Yes I agree that the compression algorithm makes differences, but I think in some MANET scenarios not all, AB From charliep@computer.org Mon Jan 14 15:32:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC1321F8B7C for ; Mon, 14 Jan 2013 15:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3B5Ulc9hago for ; Mon, 14 Jan 2013 15:32:25 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8121F8B77 for ; Mon, 14 Jan 2013 15:32:25 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TutVv-0001n2-0X; Mon, 14 Jan 2013 18:32:24 -0500 Message-ID: <50F49583.3060002@computer.org> Date: Mon, 14 Jan 2013 15:32:19 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jiazi Yi References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> In-Reply-To: <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e3c6d182ce7037a390f8daee92f6f12b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 23:32:26 -0000 Hello folks, AODVv2 does not enable any router to change the sequence number of another router. That would be quite a mistake. Regarding your question: On 1/14/2013 7:51 AM, Jiazi Yi wrote: > LOADng currently couldn't distinguish between two different message with the same sequence number and originator address. I'm wondering that other MANET protocols like OLSR, AODV, SMF (identification-based duplicate detection) won't be able to detect that either. Until last year, it was legal in DYMO for two different messages to have the same sequence number. It is not easy to state the "minimal" required set of criteria for changing a sequence number. But anyway it is not automatically wrong for a routing protocol to allow a router to re-use its same sequence number more than once. > > > This also brings me the question how further we should go in a protocol specification, to prevent "broken implementation"? A broken implementation should not be able to crash other nodes. -- Regards, Charlie P. From shares@ndzh.com Mon Jan 14 17:26:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13B321F8BBB for ; Mon, 14 Jan 2013 17:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.709 X-Spam-Level: X-Spam-Status: No, score=0.709 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jye6QmI0AkqW for ; Mon, 14 Jan 2013 17:26:58 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D05D721F8B9C for ; Mon, 14 Jan 2013 17:26:57 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=209.82.80.110; From: "Susan Hares" To: "'Henning Rogge'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> In-Reply-To: Date: Mon, 14 Jan 2013 20:26:54 -0500 Message-ID: <004e01cdf2bf$679d2680$36d77380$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zAaMHyk4DFdPHn5hKYxWQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:26:58 -0000 Henning: Thank you for continuing this conversation. I am enjoying learning from you. > What if the message with the "magic number change" gets lost? That is a common thing in wireless networks. The magic number (0/-1) is a protocol constant. It can't get lost. > How many different implementations (that is uniquely coded from > scratch) coded this sequence number rotation? I think the olsr.org (OLSRv1) code went through multiple variations of this code, with several people "testing optimizations" when the original RFC didn't worked well. This is great news. We've got experience with the algorithm. Did they find this algorithm difficult to debug? Not the code, but finding bugs in the deployment? >>At the moment we have (I think, but I have to check) a standard compliant "greater than" check in the code and some unique duplicate check system based on a 32bit >>shifting register (for each originator). Could you post the code if you get a chance? Thanks, Sue -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Monday, January 14, 2013 1:16 PM To: Susan Hares Cc: Jiazi Yi; manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) On Mon, Jan 14, 2013 at 7:05 PM, Susan Hares wrote: > Some people make the wrap number (0, 0xFFFF) as a clear indication that > something has wrapped. It is just one method, and this is another. I'm > trying to understand the pros/cons of each method. What if the message with the "magic number change" gets lost? That is a common thing in wireless networks. > How many different implementations (that is uniquely coded from > scratch) coded this sequence number rotation? I think the olsr.org (OLSRv1) code went through multiple variations of this code, with several people "testing optimizations" when the original RFC didn't worked well. > How did the debugging go? By having hundreds of users with real wifi networks willing to test the new version first? ;) At the moment we have (I think, but I have to check) a standard compliant "greater than" check in the code and some unique duplicate check system based on a 32bit shifting register (for each originator). Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From shares@ndzh.com Mon Jan 14 17:30:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC721F8B67 for ; Mon, 14 Jan 2013 17:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3getgd6cIY9 for ; Mon, 14 Jan 2013 17:30:50 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8100D21F8B4C for ; Mon, 14 Jan 2013 17:30:50 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=209.82.80.110; From: "Susan Hares" To: "'Jiazi Yi'" , References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> In-Reply-To: <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> Date: Mon, 14 Jan 2013 20:30:47 -0500 Message-ID: <005901cdf2bf$f284d7c0$d78e8740$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zAaMHyk4C+YlVf5hLRn+Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:30:51 -0000 Jiazi: Thanks for the question... The wrap (0/-1) is a protocol constant. It can't get lost.. [snip] [sue] >> How many different implementations (that is uniquely coded from >> scratch) coded this sequence number rotation? How did the debugging go? >For LOADng, which make use of this sequence number rotation, has at least 4 independent implementations. As far as I can see, I didn't notice any issue. Great news. 4 implementations means you got some mileage on making this algorithm work. I'd love to see the OLSR code -- either privately or to the list. Thanks Sue From shares@ndzh.com Mon Jan 14 17:32:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD2D21F8472 for ; Mon, 14 Jan 2013 17:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.694 X-Spam-Level: X-Spam-Status: No, score=0.694 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ0f+Ym2495c for ; Mon, 14 Jan 2013 17:32:39 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5421F8415 for ; Mon, 14 Jan 2013 17:32:38 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=209.82.80.110; From: "Susan Hares" To: "'Abdussalam Baryun'" , "'Jiazi Yi'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> In-Reply-To: Date: Mon, 14 Jan 2013 20:32:36 -0500 Message-ID: <005d01cdf2c0$330e4bf0$992ae3d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zAaMHyk4C+YlVfwFwxkc9mD/BfDA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:32:39 -0000 AB: What I mean by independent implementations is that 4 different people took the specification, and wrote the code from the specification. The four people did not share their code with each other. This is different than 4 people taking one code base and modifying it. Sue -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Monday, January 14, 2013 1:45 PM To: Jiazi Yi Cc: Susan Hares; manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) On 1/14/13, Jiazi Yi wrote: > For LOADng, which make use of this sequence number rotation, has at > least 4 independent implementations. As far as I can see, I didn't notice any issue. > Do you mean four different implementation or independent implementation. I understand the independent cannot work together (not interoperable), or am I wrong, AB From shares@ndzh.com Mon Jan 14 17:38:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4C11E80D5 for ; Mon, 14 Jan 2013 17:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-8yftyifmUT for ; Mon, 14 Jan 2013 17:38:28 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CA53B21F8692 for ; Mon, 14 Jan 2013 17:38:27 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=209.82.80.110; From: "Susan Hares" To: "'Charles E. Perkins'" , "'Jiazi Yi'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <50F49583.3060002@computer.org> In-Reply-To: <50F49583.3060002@computer.org> Date: Mon, 14 Jan 2013 20:38:24 -0500 Message-ID: <006f01cdf2c1$0306ce40$09146ac0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zAmx10HCYXMmQ4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:38:28 -0000 Charlie and Jaizi: Charlie is pointing the theoretical basis behind some of my questions. If a node kills itself by being broken - it is getting its reward for broken code. If a node can kill other nodes in the network with broken code, then it is a concern. If protocol designers can avoid any possibility of this happening - it is good. Sometimes, protocol designers cannot prevent it. And .. that my fellow nerds is why I'm asking questions. Thank you for taking time to respond to me, Sue -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Charles E. Perkins Sent: Monday, January 14, 2013 6:32 PM To: Jiazi Yi Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) Hello folks, AODVv2 does not enable any router to change the sequence number of another router. That would be quite a mistake. Regarding your question: On 1/14/2013 7:51 AM, Jiazi Yi wrote: > LOADng currently couldn't distinguish between two different message with the same sequence number and originator address. I'm wondering that other MANET protocols like OLSR, AODV, SMF (identification-based duplicate detection) won't be able to detect that either. Until last year, it was legal in DYMO for two different messages to have the same sequence number. It is not easy to state the "minimal" required set of criteria for changing a sequence number. But anyway it is not automatically wrong for a routing protocol to allow a router to re-use its same sequence number more than once. > > > This also brings me the question how further we should go in a protocol specification, to prevent "broken implementation"? A broken implementation should not be able to crash other nodes. -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From shares@ndzh.com Mon Jan 14 17:42:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E061D11E80D1 for ; Mon, 14 Jan 2013 17:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.682 X-Spam-Level: X-Spam-Status: No, score=0.682 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMbxyk6jWXSv for ; Mon, 14 Jan 2013 17:42:23 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9D11E809C for ; Mon, 14 Jan 2013 17:42:23 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=209.82.80.110; From: "Susan Hares" To: "'Abdussalam Baryun'" References: In-Reply-To: Date: Mon, 14 Jan 2013 20:42:13 -0500 Message-ID: <007101cdf2c1$8affc400$a0ff4c00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01CDF297.A22C5410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKNMEfc0p/vpZV2Ea5HwdPFegEO45bLIk1Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Addition Comparing Questions (was Re: Resolving the Reactive Protocol issue) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:42:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0072_01CDF297.A22C5410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit AB: Thank you for this kind note. As the last few days indicated, I sent in my technical questions. I am also looking for the implementation reports we did in 802.11s. I'll try to send them this week. Sue From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Thursday, December 27, 2012 7:36 AM To: Susan Hares Cc: manet@ietf.org Subject: Addition Comparing Questions (was Re: [manet] Resolving the Reactive Protocol issue) Hi Sue, I will try to answer the last two as I think it is addressed to WG participants as well, see below; On Mon, Dec 24, 2012 at 4:33 PM, Susan Hares wrote: Additional questions: 1) Will you suggest a style guide as well as a solution? In order to vote, I reviewed 2 months of email list discussion, and much of it had to do with document style issues. 2) In parallel with your query, can I still ask technical questions regarding people's comparison answer? 3) May I in parallel provide reactive trade-off from 802.11 work in mesh? This includes research and deployment experience with mesh networks (2-15 nodes). Yes, please provide with your opinion/experience as it will help in the new reactive protocol that we will be working on, 4) Is this IP only or are we considering Reactive protocols directly over layer 2? Yes, I am interested that it is only IP reactive protocol as the MANET-charter is focused on, but one of the proposed protocol seem to be working with or without IP which I believe out of scope. As mentioned by someone before on the list that some MANETs do use reactive protocols in L2. However, IMHO, considering reactive protocol directly over L2 can/may be interested to us after completing the reactive over IP. AB ------=_NextPart_000_0072_01CDF297.A22C5410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

AB:

 

Thank you for this kind note. As the last few days indicated, I sent = in my technical questions. I am also looking for the implementation = reports we did in 802.11s.  I’ll try to send them this = week.

 

Sue

 

From:= = Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: = Thursday, December 27, 2012 7:36 AM
To: Susan = Hares
Cc: manet@ietf.org
Subject: Addition Comparing = Questions (was Re: [manet] Resolving the Reactive Protocol = issue)

 

Hi Sue,

I will = try to answer the last two as I think it is addressed to WG participants = as well, see below;

On Mon, Dec = 24, 2012 at 4:33 PM, Susan Hares <shares@ndzh.com> = wrote:

Additional questions: =

1)  Will you suggest a style guide as = well as a solution?  In order to vote, I reviewed 2 months of email = list discussion, and

much of it had to do with document = style issues.

2)  In parallel with your query, can I = still ask technical questions regarding people’s comparison = answer?

3)      May I in parallel provide reactive = trade-off from 802.11 work in mesh? This includes research and = deployment experience with mesh networks (2-15 = nodes).


Yes, please provide with your opinion/experience = as it will help in the new reactive protocol that we will be working = on,
 

4)  Is this IP only or are we = considering Reactive protocols directly over layer 2? =


Yes, I am interested that it is only = IP reactive protocol as the MANET-charter is focused on, but one of the = proposed protocol seem to be working with or without IP which I believe = out of scope. As mentioned by someone before on the list that some = MANETs do use reactive protocols in L2. However, IMHO, considering = reactive protocol directly over L2 can/may be interested to us after = completing the reactive over IP.

AB

------=_NextPart_000_0072_01CDF297.A22C5410-- From charliep@computer.org Mon Jan 14 22:27:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE23621F8480 for ; Mon, 14 Jan 2013 22:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqRTyk6Pv0SJ for ; Mon, 14 Jan 2013 22:27:38 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2972021F847F for ; Mon, 14 Jan 2013 22:27:38 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tuzzl-0000KS-1e; Tue, 15 Jan 2013 01:27:37 -0500 Message-ID: <50F4F6D6.2030007@computer.org> Date: Mon, 14 Jan 2013 22:27:34 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> In-Reply-To: <50EFBACE.3040104@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866c1f13a89ff64c4b6ce3131f123a0d90350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:27:38 -0000 Hello Henning, Following up your assertion about 0/0... On 1/10/2013 11:10 PM, Henning Rogge wrote: > >> >> - If the gateway advertises a default route [e.g. 0/0], then >> any AODVv2 router receiving it won't do Route Discovery. >> The likely result will be that the gateway will become an >> intermediate routing point for every route in the network. >> To me that sounds like a terribly nonscalable design. > > One way to resolve the problem of the "default route" would be to > restrict the addresses of the MANET to a certain prefix and install a > blackhole route for it. This way the default route would have a hole > for the host routes of the MANET. Please say a bit more... - Who is restricting? Does it mean that 0/0 is "not special" but the manet "is special"? - Who is installing? - When does the installation occur? - What about a scenario when previously unrelated nodes decide to form an ad hoc network? What if all they bring to the network is their address or subnet, except for perhaps a very few that can occasionally establish an expensive link to the Internet? I'm certainly willing to agree that with enough administrative control and policy knobs, one can make default routes work. Is this also your viewpoint? But even so, I'm reluctant to go in that direction because there are quite a few competing designs to enable 0/0, which have the effect of either (i) making the protocol more complicated or (ii) introducing more requirement for administrative controls (i.e., not "ad hoc"). > > I would expect every routing protocol to be able to deliver all kinds > of prefixes through its network, including the 0.0.0.0/0 and the ::/0 > prefix. > > As long as the prefixes do not overlap this is also non-problematic > for reactive routing protocols. > Here's where more administrative controls are also useful. Any two routers advertising 0/0 are overlapping. That's something unique about 0/0, compared to all other prefixes which would be likely encountered in the network. -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Mon Jan 14 22:32:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FC521F8ACE for ; Mon, 14 Jan 2013 22:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-w-1DZy4yal for ; Mon, 14 Jan 2013 22:32:34 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C994021F8497 for ; Mon, 14 Jan 2013 22:32:33 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv04W-0006Vp-RC for manet@ietf.org; Tue, 15 Jan 2013 07:32:32 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv04W-0007C7-OZ for manet@ietf.org; Tue, 15 Jan 2013 07:32:32 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 07:32:32 +0100 Message-ID: <50F4F7F8.9080200@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 07:32:24 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <004e01cdf2bf$679d2680$36d77380$@ndzh.com> In-Reply-To: <004e01cdf2bf$679d2680$36d77380$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080008090903050008060505" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16493/Tue Jan 15 06:43:54 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c4d5118c678b4c5efdde27bcb7d1073a Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:32:35 -0000 --------------ms080008090903050008060505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 02:26 AM, Susan Hares wrote: > Henning: > > Thank you for continuing this conversation. I am enjoying learning fro= m > you. > > > >> What if the message with the "magic number change" gets lost? That is = a > common thing in wireless networks. > > The magic number (0/-1) is a protocol constant. It can't get lost. I mean it can get lost in transmission. Wireless networks are unreliable = and have packet loss. So the packet with "here is the magic number, I=20 restarted my sequence numbers" could never arrive on the receiving nodes.= > This is great news. We've got experience with the algorithm. > Did they find this algorithm difficult to debug? Not the code, but find= ing > bugs in the deployment? Finding bugs in a community owned mesh network can be hard and painful.=20 Some people will have quite a technical knowledge and will be very=20 helpful. Others may not. Still, if the internet doesn't work, people will start complain quickly. >>> At the moment we have (I think, but I have to check) a standard compl= iant > "greater than" check in the code and some unique duplicate check system= > based on a 32bit >>shifting register (for each originator). > > Could you post the code if you get a chance? All code developed at olsr.org is on the website. The duplicate code is=20 here: http://olsr.org/git/?p=3Dolsrd.git;a=3Dblob;f=3Dsrc/duplicate_set.h;h=3De= 5a761cb980e0ea6fa527aeaeac118e60ef4386c;hb=3Dmaster http://olsr.org/git/?p=3Dolsrd.git;a=3Dblob;f=3Dsrc/duplicate_set.c;h=3D3= 04d02c20b86f4dbe9619c934cadd1f4d03bfdc7;hb=3Dmaster v I am also working on a complete rewrite of our codebase to implement=20 OLSRv2 in the long run, you will find the code in two repositories on=20 olsr.org too: The new API for our program. Think about it as "routing agent without=20 the routing protocol". I hope we will use it for other programs too. http://olsr.org/git/?p=3Doonf_api.git;a=3Dsummary The NHDP/OLSRv2 application, which is using the API mentioned (at the=20 moment only NHDP): http://olsr.org/git/?p=3Dolsrd2.git;a=3Dsummary Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080008090903050008060505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUwNjMyMzBaMCMGCSqGSIb3DQEJBDEWBBSKlv2RWultlNjyZRpjjkczNmm+1zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAIFirQax7nr9c5bxC5VxIpvfwUEULyKgUv5PdfTQmVPH8 DKOcCGPeekMq3EEZ54LC8kbVq/raNQFFKj2MvAFnvqd3oVU+gNe44zb+pWdV4XnzCiPVrUzs w7lyvjTw1jjFBAP6JeiPaz0rvGwJR9Qgkz6A3f56+06i9QZpM2gQ8KvVel1sZ9oQuF3rpu0L bWpgma3p6J8RKqqUy/TSvQBkr1PY9akFxCFgXSsjGglsvPAsq8gQqJfVcC6fFlQol/Xzvltm +bChbRXjQr2IGBX5zOKo+gNOJJ6lBBrYZgsL74OXE3GYcEqgkoXRJlO8jtlD4BfSpJsFuvyG PP1cb6C8oAAAAAAAAA== --------------ms080008090903050008060505-- From henning.rogge@fkie.fraunhofer.de Mon Jan 14 22:35:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA7E21F841A for ; Mon, 14 Jan 2013 22:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnLISfl4NWbY for ; Mon, 14 Jan 2013 22:35:13 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B861F21F8203 for ; Mon, 14 Jan 2013 22:35:12 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv074-0006gv-Vh for manet@ietf.org; Tue, 15 Jan 2013 07:35:10 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv074-0007Lx-T1 for manet@ietf.org; Tue, 15 Jan 2013 07:35:10 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 07:35:10 +0100 Message-ID: <50F4F89D.1050500@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 07:35:09 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <50F49583.3060002@computer.org> <006f01cdf2c1$0306ce40$09146ac0$@ndzh.com> In-Reply-To: <006f01cdf2c1$0306ce40$09146ac0$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000301000906080607050200" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16493/Tue Jan 15 06:43:54 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:35:14 -0000 --------------ms000301000906080607050200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 02:38 AM, Susan Hares wrote: > Charlie and Jaizi: > > Charlie is pointing the theoretical basis behind some of my questions. > > If a node kills itself by being broken - it is getting its reward for b= roken > code. > If a node can kill other nodes in the network with broken code, then it= is a > concern. > > If protocol designers can avoid any possibility of this happening - it = is > good. > Sometimes, protocol designers cannot prevent it. > > And .. that my fellow nerds is why I'm asking questions. As long as you do not run some kind of authentication that prevents=20 external attacks or spoofing identity by other routers, its very=20 difficult (impossible?) to build a network that cannot be wrecked by an=20 attacker. I would expect OLSR/AODV/LOADng nodes would not crash, but the routing=20 itself would not work until the attack stops. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000301000906080607050200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUwNjM1MDlaMCMGCSqGSIb3DQEJBDEWBBTuAPtfDBOJcXcdj7EabDfH7pxzPDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAoK3749rMnNrBuyuOkW6vUhtiY2dY/1hLOWjQ0DUTS3dq hy1oUU4IdlJmAodzCXlz69hlnTh2oyZnNxScO0+Vi1jqjLk6u5f81JpdG6ZvbThBXjkbCj6n lKB1LcKnRfJtFmI26WLepT/orv7lIk0ban4BvZ4Zi4DCQgM8O3JYDnWdp+4xy19Ahg3vSxBn fqDwjUzyVcsGNoJ4wNIr9UaERDzyN9q4vYDxbTN4YsVZjSQzOoUBBjBYvrLOMIO3NvH4Mtwh UGPywtkDv1bC1CTHaJmvAglV2xXEbvaDItgP3TAWlTGVCOHJQ+fa7r0YI9s2GSWi2kjSztJ6 BtpEVdcSqAAAAAAAAA== --------------ms000301000906080607050200-- From henning.rogge@fkie.fraunhofer.de Mon Jan 14 22:42:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD86821F8698 for ; Mon, 14 Jan 2013 22:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU1SgCc4HOgG for ; Mon, 14 Jan 2013 22:42:37 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D658721F8481 for ; Mon, 14 Jan 2013 22:42:36 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv0EG-0001OV-6E; Tue, 15 Jan 2013 07:42:36 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv0EG-0007Tj-3W; Tue, 15 Jan 2013 07:42:36 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 07:42:35 +0100 Message-ID: <50F4FA5A.2040507@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 07:42:34 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles E. Perkins" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> In-Reply-To: <50F4F6D6.2030007@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090307050401020206040900" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16493/Tue Jan 15 06:43:54 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 912e0972ada2ab87c171579937f55793 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:42:38 -0000 --------------ms090307050401020206040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 07:27 AM, Charles E. Perkins wrote: > Please say a bit more... > > - Who is restricting? > Does it mean that 0/0 is "not special" but the manet "is special"? I think reactive routing protocols need some special care for prefixes.=20 Because of their "on demand" aspect, they might miss a route with a=20 longer prefix because the shorter prefix is still there. > - Who is installing? Could be done by the administrator during the setup of the node. Something like "this subnet is reserved for host routes, install a=20 blackhole route to get no-route-available events". > - What about a scenario when previously unrelated nodes decide to > form an ad hoc network? > What if all they bring to the network is their address or subnet, Where do they get the address/subnet from? If they all have the same=20 subnet, they could easily install a blackhole route for it. > except for perhaps a very few that can occasionally establish an > expensive link to the Internet? I don't think building a network of nodes by different parties and=20 giving all of them a totally random network address is a good idea. > I'm certainly willing to agree that with enough administrative control > and policy knobs, one can make default routes work. Is this also your > viewpoint? Its not only default routes, its any kind of routes. If you have a node that announces a prefix which overlaps with=20 host-routes of the network, you are in trouble in reactive protocols. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090307050401020206040900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUwNjQyMzRaMCMGCSqGSIb3DQEJBDEWBBR39YBYcbbH4bLVixB8ldUmV3pGCjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAk+Dlq9mDFj0TEDEPlglKz7AhXnsxXGDjx1Owimchqe9+ ks+0y6xwglepfycz+0528QuXXJBiu7lN5CIR149j9ALvsbRI4vo4G8AbEyIOdbLi3BQ6Nv4u Qtb6lonps2zcmECR/NtPoHdrGf/bqqmCSaDXlSB85rdSwF2POWRqGMl175hm9RUBCVRuQjas nUAaZAwMgiGnzPM1/SBPTyQuIqlRLKshqqn26LFnL37pN8DQhDAZC9lXTg7WuF2+uNqLvcdV Y+oAP3J7GA2gPzMl93IUqpVej2YA/hqeYtbBsHW3PJC5vQrGl5y10EpNlXPls3NHkvTdNQ3S codR+xmwewAAAAAAAA== --------------ms090307050401020206040900-- From charliep@computer.org Mon Jan 14 22:50:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9909C21F8834 for ; Mon, 14 Jan 2013 22:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDz3P1RsJJSf for ; Mon, 14 Jan 2013 22:50:14 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id EABBB21F8788 for ; Mon, 14 Jan 2013 22:50:13 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tv0LS-0004vt-Kf; Tue, 15 Jan 2013 01:50:02 -0500 Message-ID: <50F4FC18.6050009@computer.org> Date: Mon, 14 Jan 2013 22:50:00 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Susan Hares References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> In-Reply-To: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> Content-Type: multipart/alternative; boundary="------------090107080306080709030705" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865fb11fab24f6239eaa6671ebafcf93d2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:50:17 -0000 This is a multi-part message in MIME format. --------------090107080306080709030705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Sue and all, In earlier email, I pointed out that AODVv2 could eliminate the requirement for a distinguished value of the SeqNum. I can go either way on this issue -- either to keep the distinguished value, or get rid of it. On 1/13/2013 9:03 PM, Susan Hares wrote: > > > Technical issue 1: Sequence numbers > > DYMO-25 Text: > > > Q1: How is the unique node address selected? Did the WG group have a > security/theoretical discussion on using the loopback IP address > versus other addresses? (e.g. DOS on loopback addresses) If you can > point to an archive discussion, I'm glad to go read it. I would expect > that the sharp minds in this WG would have debated these points. > There have been discussions about using loopback addresses for some functions, but I'm not clear about why that would be a good idea for Sequence Numbers. Anyway, I think all the [manet] protocols that have been discussed lately assume that each node has a unique IP address, and the way that the IP address is assigned is out of scope for the routing protocol specification. Given that, I think that the unique IP address should naturally be associated with the router's SeqNum. Or it could be that I am missing the point here. > > #2 Sequence numbers always wrap and sequence number reuse depends on > the time and/or wrap detection. > > Sequence number time is usually 2* the wrap time so junk can clear > from the network. Therefore the equation is: > > MAX_SEQ_LIFETIME = 2 * normal_wrap_time > I think you meant half the wrap time, not twice the wrap time. > Distance vector routes may encounter route cycling (count to infinity > in RIP, BGP MED harmful/BGP flapping) in certain topologies. Rapidly > changing mobile topologies may cycle through topologies that do and do > not cause this route fluctuation. The validity timer and max-sequence > timer seems to be addressing this issue. > > Q2: Am I correct? > The validity timer is defined in RFC 5444 and so I think it must be handled in general. It's useful for intermediate RREP and for path accumulation also. > The timers in DYMO-24 are: > > +------------------------------+-------------+ > | Name | Value | > +------------------------------+-------------+ > | ACTIVE_INTERVAL | 5 second | > | MAX_IDLETIME | 200 seconds | > | MAX_SEQNUM_LIFETIME | 300 seconds | > | ROUTE_RREQ_WAIT_TIME | 2 seconds | > | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | > | RREQ_HOLDDOWN_TIME | 10 seconds | > > --------------------------------------------- > > Here's my set of equations: > > Validity timer ::=max time before route declared invalid > > = ACTIVE_INTERNAL + MAX_IDLETIME -- > (Current_time-Routelast.used) > > Expired route ::= route expired, but sequence number cannot be used > > :: = valid_time < expired route < MAX_SEQNUM_TIME > The sequence number for an Expired Route could be used in a RREQ attempting to re-establish that route. In fact this is the only reason to keep Expired Routes. > Q3: Can you correct these equations or add to them? > > Architecture questions: > > 1.How does MAX_SEQNUM_TIME interact with the real wrapping functions > during fast node motion to slow node motion so that links come and go > (per 2c of Gabblek, Hofner, Portman and Tan's diagram > (non-opt_incSQN2.pdf) > MAX_SEQNUM_TIME, as you mention, is related to how long a SeqNum is valid before wrap-around might occur. It also is defined to be the amount of time a node must remain quiescent after reboot in case the router's own sequence number is not stored in non-volatile memory. That means that MAX_SEQNUM_TIME might typically be far less than half the wraparound time. > 2. What conditions cause all nodes to engage in a sequence number > wrap? For example, would fast mobility of nodes with fast link > breakage cause these problems? > It would have to be pretty darned fast. > 3. One important issue is the restart of things after power loss or > reboot (likely from software errors). Does the node going down > require that a sequence number to be maintained in NVRAM? > It's better to be maintained in NVRAM. Then the node could start operation immediately after reboot, using it's old SeqNum as its first value after reboot. This also required maintaining last_used_time. > 4.Is there a reason for the Address Block TLV route passed through to > time out different that the originating node? If so, does (or does it > not) impact the sequence number wrap. > No, the originating router timeout should be approximately the same as the timeout for every other router seeing the AddrBlkTLV. -- Regards, Charlie P. --------------090107080306080709030705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Sue and all,

In earlier email, I pointed out that AODVv2 could eliminate the requirement
for a distinguished value of the SeqNum.  I can go either way on this issue --
either to keep the distinguished value, or get rid of it. 

On 1/13/2013 9:03 PM, Susan Hares wrote:

Technical issue 1: Sequence numbers

 

DYMO-25 Text:

 


Q1: How is the unique node address selected?  Did the WG group have a security/theoretical discussion on using the loopback IP address versus other addresses? (e.g. DOS on loopback addresses) If you can point to an archive discussion, I’m glad to go read it. I would expect that the sharp minds in this WG would have debated these points.


There have been discussions about using loopback addresses for some
functions, but I'm not clear about why that would be a good idea for
Sequence Numbers.

Anyway, I think all the [manet] protocols that have been discussed
lately assume that each node has a unique IP address, and the way
that the IP address is assigned is out of scope for the routing
protocol specification.  Given that, I think that the unique IP address
should naturally be associated with the router's SeqNum.  Or it could
be that I am missing the point here.

 


 

#2 Sequence numbers always wrap and sequence number reuse depends on the time and/or wrap detection.

 

 

Sequence number time is usually 2* the wrap time so junk can clear from the network. Therefore the equation is:

 

MAX_SEQ_LIFETIME = 2 * normal_wrap_time


I think you meant half the wrap time, not twice the wrap time.

 

Distance vector routes may encounter route cycling (count to infinity in RIP, BGP MED harmful/BGP flapping) in certain topologies. Rapidly changing mobile topologies may cycle through topologies that do and do not cause this route fluctuation.  The validity timer and max-sequence timer seems to be addressing this issue.

 

Q2: Am I correct?


The validity timer is defined in RFC 5444 and so I think it must be
handled in general.  It's useful for intermediate RREP and for path
accumulation also.

 

The timers in DYMO-24 are:

 

              +------------------------------+-------------+
              |             Name             |    Value    |
              +------------------------------+-------------+
              |        ACTIVE_INTERVAL       |   5 second  |
              |         MAX_IDLETIME         | 200 seconds |
              |      MAX_SEQNUM_LIFETIME     | 300 seconds |
              |     ROUTE_RREQ_WAIT_TIME     |  2 seconds  |
              | UNICAST_MESSAGE_SENT_TIMEOUT |   1 second  |
              |      RREQ_HOLDDOWN_TIME      |  10 seconds |

---------------------------------------------

 

Here’s my set of equations:

  

Validity timer ::=max time before route declared invalid

               = ACTIVE_INTERNAL + MAX_IDLETIME – (Current_time-Routelast.used)

 

Expired route ::=  route expired, but sequence number cannot be used

              :: = valid_time < expired route < MAX_SEQNUM_TIME


The sequence number for an Expired Route could be used in a RREQ
attempting to re-establish that route.  In fact this is the only reason
to keep Expired Routes.

 

Q3: Can you correct these equations or add to them?

 

Architecture questions:

 

1. How does MAX_SEQNUM_TIME interact with the real wrapping functions during fast node motion to slow node motion so that links come and go (per 2c of Gabblek, Hofner, Portman and Tan’s diagram (non-opt_incSQN2.pdf)


MAX_SEQNUM_TIME, as you mention, is related to how long a SeqNum is
valid before wrap-around might occur.  It also is defined to be the amount
of time a node must remain quiescent after reboot in case the router's
own sequence number is not stored in non-volatile memory.  That means
that MAX_SEQNUM_TIME might typically be far less than half the wraparound
time.



 

2.  What conditions cause all nodes to engage in a sequence number wrap?  For example, would fast mobility of nodes with fast link breakage cause these problems?


It would have to be pretty darned fast.

 

3.  One important issue is the restart of things after power loss or reboot (likely from software errors).  Does the node going down require that a sequence number to be maintained in NVRAM?


It's better to be maintained in NVRAM.  Then the node could start operation
immediately after reboot, using it's old SeqNum as its first value after reboot.
This also required maintaining last_used_time.

 

 

4. Is there a reason for the Address Block TLV route passed through to time out different that the originating node? If so, does (or does it not) impact the sequence number wrap.


No, the originating router timeout should be approximately the same
as the timeout for every other router seeing the AddrBlkTLV.

-- 
Regards,
Charlie P.
--------------090107080306080709030705-- From charliep@computer.org Mon Jan 14 23:07:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF43C21F8AB7 for ; Mon, 14 Jan 2013 23:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65KHlJvzlLC2 for ; Mon, 14 Jan 2013 23:07:23 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3004521F8AA6 for ; Mon, 14 Jan 2013 23:07:23 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tv0cE-0003MH-1z; Tue, 15 Jan 2013 02:07:22 -0500 Message-ID: <50F50027.3040801@computer.org> Date: Mon, 14 Jan 2013 23:07:19 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> In-Reply-To: <50F4FA5A.2040507@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864e5becee834452875e7ff21770ab3c87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:07:24 -0000 Hello Henning, On 1/14/2013 10:42 PM, Henning Rogge wrote: > On 01/15/2013 07:27 AM, Charles E. Perkins wrote: >> Please say a bit more... >> >> - Who is restricting? >> Does it mean that 0/0 is "not special" but the manet "is special"? > > I think reactive routing protocols need some special care for > prefixes. Because of their "on demand" aspect, they might miss a route > with a longer prefix because the shorter prefix is still there. This is exactly my point, restated. Or, to say it the other way around -- as long as the nodes aren't advertising 0/0, no special care is needed except that the AODVv2 routers have to obey the universal rule for advertising a subnet prefix. > >> - Who is installing? > > Could be done by the administrator during the setup of the node. As currently specified, AODVv2 does not require any such extra installation instructions. Only the address -- that's it. > > Something like "this subnet is reserved for host routes, install a > blackhole route to get no-route-available events". Yes, that is exactly my point. Something like that, or something like one of the other half-dozen ways of fixing the problem. > >> - What about a scenario when previously unrelated nodes decide to >> form an ad hoc network? >> What if all they bring to the network is their address or subnet, > > Where do they get the address/subnet from? If they all have the same > subnet, they could easily install a blackhole route for it. Please say more about what the requirements are when there are 50 nodes, 10 of which lie on a subnet, and one of the nodes can have an Internet connection when necessary. How many nodes get exactly which blackhole route? Do they all need the same network administrator? > > >> except for perhaps a very few that can occasionally establish an >> expensive link to the Internet? > > I don't think building a network of nodes by different parties and > giving all of them a totally random network address is a good idea. Well, it absolutely does work. > >> I'm certainly willing to agree that with enough administrative control >> and policy knobs, one can make default routes work. Is this also your >> viewpoint? > > Its not only default routes, its any kind of routes. For all other routes likely to be encountered, the noted phenomenon of gateway congestion is quite unlikely to occur. > > If you have a node that announces a prefix which overlaps with > host-routes of the network, you are in trouble in reactive protocols. A router can't advertise a prefix unless it guarantees the ability to reach nodes with addresses on that prefix. Otherwise, the router is just spreading falsehoods and bad things can happen. Just because it's an ad hoc network does not mean that a node in the network can wreck the addressing convention of the address family from which it takes addresses. -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Mon Jan 14 23:18:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB4821F84F8 for ; Mon, 14 Jan 2013 23:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QXBR1gHh2ix for ; Mon, 14 Jan 2013 23:18:00 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3621F8481 for ; Mon, 14 Jan 2013 23:18:00 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv0mV-0004aQ-Ji; Tue, 15 Jan 2013 08:17:59 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv0mV-0008MG-H1; Tue, 15 Jan 2013 08:17:59 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 08:17:59 +0100 Message-ID: <50F502A6.2010402@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 08:17:58 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles E. Perkins" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> In-Reply-To: <50F50027.3040801@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000204030606090503080804" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16493/Tue Jan 15 06:43:54 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b6363c759feafef6090591a79445ea96 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:18:01 -0000 --------------ms000204030606090503080804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 08:07 AM, Charles E. Perkins wrote: > Or, to say it the other way around -- as long as the nodes aren't > advertising 0/0, > no special care is needed except that the AODVv2 routers have to obey t= he > universal rule for advertising a subnet prefix. I disagree. (example below) >>> - Who is installing? >> >> Could be done by the administrator during the setup of the node. > > As currently specified, AODVv2 does not require any such extra > installation instructions. Only the address -- that's it. > >> >> Something like "this subnet is reserved for host routes, install a >> blackhole route to get no-route-available events". > > Yes, that is exactly my point. Something like that, or something > like one of the other half-dozen ways of fixing the problem. Which shows that there IS a problem. >>> - What about a scenario when previously unrelated nodes decide to >>> form an ad hoc network? >>> What if all they bring to the network is their address or subnet,= >> >> Where do they get the address/subnet from? If they all have the same >> subnet, they could easily install a blackhole route for it. > > Please say more about what the requirements are when there are > 50 nodes, 10 of which lie on a subnet, and one of the nodes can > have an Internet connection when necessary. > > How many nodes get exactly which blackhole route? > Do they all need the same network administrator? >>> except for perhaps a very few that can occasionally establish an >>> expensive link to the Internet? >> >> I don't think building a network of nodes by different parties and >> giving all of them a totally random network address is a good idea. > > Well, it absolutely does work. Which doesn't make it a good idea in my opinion. Especially not if you=20 want to support any kind of gateway/prefix announcement. A better way might be to switch to IPv6 and get your random addresses=20 from a global /64 prefix... less chance to get a collision AND an easy=20 way to prevent shorter prefixes to block your host routes. >>> I'm certainly willing to agree that with enough administrative contro= l >>> and policy knobs, one can make default routes work. Is this also you= r >>> viewpoint? >> >> Its not only default routes, its any kind of routes. > > For all other routes likely to be encountered, the noted > phenomenon of gateway congestion is quite unlikely to > occur. > >> If you have a node that announces a prefix which overlaps with >> host-routes of the network, you are in trouble in reactive protocols. > > A router can't advertise a prefix unless it guarantees the > ability to reach nodes with addresses on that prefix. > Otherwise, the router is just spreading falsehoods and > bad things can happen. Just because it's an ad hoc network > does not mean that a node in the network can wreck the > addressing convention of the address family from which it > takes addresses. Lets take an example. A network of mesh nodes with random addresses. One of them is also attached to a local ethernet with the the configured = prefix 10.0.0.0/8 (a common prefix for a home network) and wants this=20 nodes to be available on the mesh. If it publishes this prefix, it could block other nodes who randomly got = allocated a host address from this range. --- The other way around, if all your nodes grab their random IP address from 10.0.0.0/8, its easy = to forbid prefixes to be announced from this range AND install a=20 blackhole route for 10.0.0.0/8, so even shorter prefixes cannot block=20 the "still to be discovered" host routes of the mesh. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000204030606090503080804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUwNzE3NThaMCMGCSqGSIb3DQEJBDEWBBSagFbfxf7IVsMrQvfKgjJWMyfKqjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEASL1viR4yaejl6Q2PZ/kEJjn47kEcFkuvb176TnryO+CG fBWhWBP6GgOAn5HbjIsTi/0zqnnspOkR7TOH23Z/nyelf3j0YW62NyeisIyJ7FNvxwa9Q+X2 YcB2Oxs+9PT2HFoTubZBeKwxPasj+XOb2ZzOonfEhWGcDrFYf786X9kE/NMParpPMcIIQ9ES 5I+FuhSxs4so6zOUQY5mUPRwXZgGsOrlSuq2NraGNLKwOm8fTUWCPjBYBMVlh6BKL0tp2dRJ iAwwa/TtPkMuZZH356AtYwDTZO5fx+O1KOJ6G6m9RXXzFCfI02s6tbxOcA0R/RxoOPTs58zb CTXZzm7Z1wAAAAAAAA== --------------ms000204030606090503080804-- From charliep@computer.org Tue Jan 15 00:35:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF49F21F844F for ; Tue, 15 Jan 2013 00:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67nxbDAx-jkx for ; Tue, 15 Jan 2013 00:35:36 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id B260021F842F for ; Tue, 15 Jan 2013 00:35:36 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tv1zb-0006Pz-Oh; Tue, 15 Jan 2013 03:35:35 -0500 Message-ID: <50F514D5.1030204@computer.org> Date: Tue, 15 Jan 2013 00:35:33 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> In-Reply-To: <50F502A6.2010402@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864fa7595b2fad5601aa00be7d9c3a0bfa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:35:37 -0000 Hello Henning, On 1/14/2013 11:17 PM, Henning Rogge wrote: > >>> >>> Something like "this subnet is reserved for host routes, install a >>> blackhole route to get no-route-available events". >> >> Yes, that is exactly my point. Something like that, or something >> like one of the other half-dozen ways of fixing the problem. > > Which shows that there IS a problem. Well... I'm not sure what you're saying here. I do not personally want to write the specification for advertising 0/0. I think it leads to problems that do not require a reactive-protocol-specific solution. You agree there is a problem. > >>> >>> Where do they get the address/subnet from? If they all have the same >>> subnet, they could easily install a blackhole route for it. >> >> Please say more about what the requirements are when there are >> 50 nodes, 10 of which lie on a subnet, and one of the nodes can >> have an Internet connection when necessary. >> >> How many nodes get exactly which blackhole route? >> Do they all need the same network administrator? > > > > >>>> except for perhaps a very few that can occasionally establish an >>>> expensive link to the Internet? >>> >>> I don't think building a network of nodes by different parties and >>> giving all of them a totally random network address is a good idea. >> >> Well, it absolutely does work. > > Which doesn't make it a good idea in my opinion. Especially not if you > want to support any kind of gateway/prefix announcement. I'd like to support Mobile IP in the ad hoc network... We did it before and it works great. I've already cited the document. And it works even if the gateway is advertising a prefix. These are by no means mutually exclusive functions. > > A better way might be to switch to IPv6 and get your random addresses > from a global /64 prefix... less chance to get a collision AND an easy > way to prevent shorter prefixes to block your host routes. If you're trying to convince me to re-run the playbook from the former [autoconf] working group, l will just for now claim that this proves my point that we should delay the matter. > >>>> I'm certainly willing to agree that with enough administrative control >>>> and policy knobs, one can make default routes work. Is this also your >>>> viewpoint? >>> >>> Its not only default routes, its any kind of routes. >> >> For all other routes likely to be encountered, the noted >> phenomenon of gateway congestion is quite unlikely to >> occur. > > >>> If you have a node that announces a prefix which overlaps with >>> host-routes of the network, you are in trouble in reactive protocols. >> >> A router can't advertise a prefix unless it guarantees the >> ability to reach nodes with addresses on that prefix. >> Otherwise, the router is just spreading falsehoods and >> bad things can happen. Just because it's an ad hoc network >> does not mean that a node in the network can wreck the >> addressing convention of the address family from which it >> takes addresses. > > Lets take an example. > > A network of mesh nodes with random addresses. > > One of them is also attached to a local ethernet with the the > configured prefix 10.0.0.0/8 (a common prefix for a home network) and > wants this nodes to be available on the mesh. The net-10 subnet wants its net-10 addressable nodes to be available for communications across the entire MANET, if I understand your hypothesis... > > If it publishes this prefix, it could block other nodes who randomly > got allocated a host address from this range. a) it can't publish the prefix if it doesn't own the prefix. b) you can't mix random addressing and subnets. This is because subnets "own" their address range. Somehow I feel I must be missing your point. Are we talking about net-10 allocations from several routers in the same MANET? Ouch-e-roonie (to use the technical terminology). NAT too? Pour me a double. > > The other way around, > > if all your nodes grab their random IP address from 10.0.0.0/8, its > easy to forbid prefixes to be announced from this range AND install a > blackhole route for 10.0.0.0/8, so even shorter prefixes cannot block > the "still to be discovered" host routes of the mesh. On which of the 50 nodes is the blackhole route installed? What if the net-10 router only comes up the day after tomorrow? Who's administering the other nodes? It's "easy" if there's a network administrator handy (not too ad-hoc). Actually, I'm not clear on your scenario, or even whether we mean the same thing by "blackhole route": http://en.wikipedia.org/wiki/Null_route And I am really not at all understanding why this is germane to what needs to be done soon for reactive routing protocol specification. -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Jan 15 00:51:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0986721F87C8 for ; Tue, 15 Jan 2013 00:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjXf2-ej7ihL for ; Tue, 15 Jan 2013 00:51:08 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCE221F8783 for ; Tue, 15 Jan 2013 00:51:08 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so4386326vbb.38 for ; Tue, 15 Jan 2013 00:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gCz8Xx40AA1mict9vEzsXXqlZCkfKRHa7Uf8i/BPCJ4=; b=MbMuV8RKEGlIpBg34V9WFvylgkCJuDdRcrYpZ9mCUosin+TnaS5diRdGX6B7/rdb3w nVfHvVTeSFqpuyq+OZ2fSqYNxBczzSMO6pbvUJpEfTZEbxaM8X5qa2W9tCBnCl+FjUvo 6x5nWAZzMR8CMNkR5v74sdEFyaFAYxAciERlx6/1Pmcb5Sr4C8pA0n2Z921OW379r5C9 wDc90R3xSIdS/Unxg+wrIM5NbpsnHe5FDmhBYveqzgKF1aEI9tpHVo+LDYhBrwgWYxy1 7MCCHFiXZfi0BJnxMB/G/3hTmRD2eeZRUeY+LvBG77XGnIIB2TBe+cGpYersUQiSMxis JiFQ== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr105006991vco.22.1358239867697; Tue, 15 Jan 2013 00:51:07 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 00:51:07 -0800 (PST) In-Reply-To: <005d01cdf2c0$330e4bf0$992ae3d0$@ndzh.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> <005d01cdf2c0$330e4bf0$992ae3d0$@ndzh.com> Date: Tue, 15 Jan 2013 09:51:07 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:51:09 -0000 Hi Sue, Yes in your understanding it is ok, which I think any one on the list will think, but does thoes 4 routers with independent implementation can work together in same network. In my opinion if understanding independent the way you defined then they should work together as long they are following the same IETF draft specification. In other understandning of independent, which I think that poster ment by *independent*, that they cannot work together, because they yes follow the specification but they are implemented in different architecture layers. So to say they follow the specification but not all 4 implementation use the RFC5444's assigned port. However, I may be wrong, but just making sure I understand the meaning :) AB On 1/15/13, Susan Hares wrote: > AB: > > What I mean by independent implementations is that 4 different people took > the specification, and wrote the code from the specification. The four > people did not share their code with each other. > > This is different than 4 people taking one code base and modifying it. > > Sue > > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: Monday, January 14, 2013 1:45 PM > To: Jiazi Yi > Cc: Susan Hares; manet@ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence numbers > (warning long post) > > On 1/14/13, Jiazi Yi wrote: >> For LOADng, which make use of this sequence number rotation, has at >> least 4 independent implementations. As far as I can see, I didn't notice > any issue. >> > > Do you mean four different implementation or independent implementation. I > understand the independent cannot work together (not interoperable), or am > I > wrong, > > AB > > From abdussalambaryun@gmail.com Tue Jan 15 01:45:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4284421F8B2F for ; Tue, 15 Jan 2013 01:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34B8A1Y1vmGO for ; Tue, 15 Jan 2013 01:45:04 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06B21F8B1A for ; Tue, 15 Jan 2013 01:45:04 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so4516484vcb.15 for ; Tue, 15 Jan 2013 01:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sfi+Y1waoswuzqPwynZTr/o6e43fUA0TH9KGqZRfE8c=; b=qPK6WFIxwYUov+vBkOMlnBP3ObZxhGNfc9xjPfZpTR3JgREv4Zl8N8XoZbnc1WWkUB eGOjTTcWBTnbtiGggCvEqj3UUugoYVIynVnUXPZPzcam0oAyrCK/5MXfzCoi7dfok8Aq tdSgcTrTH2d0u6TrBIHcgc4qUFm/jz3tPeiIzDwS2kUqbq83EMI284Nqpessp6Q4XqlZ YmPpE+blQjxJ11mv9Wt0Y9g19R/PeQAf1hARodSkxDWhIQoVySnzuUq9MABM6u9H7ilA rgKnysPo911aLdOkMZWYLxfxg9SHVc2OyoUqdcilbp1Q/gqvUtYM+Um7Fs7EszMIYtXS tcgA== MIME-Version: 1.0 Received: by 10.58.198.135 with SMTP id jc7mr105996642vec.51.1358243103648; Tue, 15 Jan 2013 01:45:03 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 01:45:03 -0800 (PST) In-Reply-To: <50C8CF75.1090406@computer.org> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> Date: Tue, 15 Jan 2013 10:45:03 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:45:05 -0000 Hi Charlie, I want to understand the subject title: stability vs gateway spec, What you mean by stability, there was no discussion on it in thread. Do you mean network stability? AB On 12/12/12, Charles E. Perkins wrote: > > Hello Chris, > > Yes, if the WG decides to put in something about gateways in the > document, that will require more work. I don't know if you had > a look at the expired document that I posted a few days ago on > the subject of gateways, but the discussion on the list also in my > opinion shows that the matter is not settled for OLSRv2 either. > I'm sure you can sift through the emails and find various points > that are not settled and still worthy of discussion. > > I strongly believe that the subject is important enough to merit > a separate effort. And, while it is true that proactive is easier, > there are many design issues in common, so that a separate > document could be made to apply to both proactive and reactive. > > Perhaps after my local fires (IEEE, etc.) have died down in a few > more days, I'll write up a requirements draft for Gateways that > enumerates the issues raised here on the list as well as others > discussed in the past. It's not as easy as just saying "0/0". > > > > On 12/12/2012 10:03 AM, Dearlove, Christopher (UK) wrote: >> I think given that there was discussion just in the last week or two on >> the status of gateways, that's just one example where features aren't >> stable. And I don't believe the WG has actually expressed a view on much >> of what's in or not in the document. >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From salo@saloits.com Tue Jan 15 01:49:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B421F894C for ; Tue, 15 Jan 2013 01:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlQV42+nSmV2 for ; Tue, 15 Jan 2013 01:49:03 -0800 (PST) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id E80F721F88F0 for ; Tue, 15 Jan 2013 01:49:02 -0800 (PST) Received: from [192.168.255.119] (thinkpad2.saloits.com [192.168.255.119]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id r0F9mxqO026281; Tue, 15 Jan 2013 03:49:00 -0600 Message-ID: <50F5260D.1010409@saloits.com> Date: Tue, 15 Jan 2013 03:49:01 -0600 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: manet@ietf.org References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> <005d01cdf2c0$330e4bf0$992ae3d0$@ndzh.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:49:03 -0000 > Yes in your understanding it is ok, which I think any one on the list > will think, but does thoes 4 routers with independent implementation > can work together in same network. In my opinion if understanding > independent the way you defined then they should work together as long > they are following the same IETF draft specification. It is generally expected that "independent implementations" will interoperate. In particular, see RFC 2026, "Internet Standards Process", which includes the following: Thus, a candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard. (Having said that, there appears to be a range of views as to what "interoperable" means. For some, it means: if your implementation conforms to the specification, it is assured of interoperating with any other conforming implementation. For others, it seems to mean: if you implement the same options that I do, then our implementations will interoperate; if you implement different options, then well...) -tjs From abdussalambaryun@gmail.com Tue Jan 15 02:33:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ADD21F8551 for ; Tue, 15 Jan 2013 02:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uRBS1DVKVYS for ; Tue, 15 Jan 2013 02:32:59 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78921F8546 for ; Tue, 15 Jan 2013 02:32:59 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so307254vbi.32 for ; Tue, 15 Jan 2013 02:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=3uGyfJqUvf2omSpLlZI0aU3itnwzjc83JfI2Mc7El+4=; b=JNgcR4qUudEnyCNliZR3aA0yh5XmiaBgVutAssefhXV114+gBqxcUthQxbRrdGRb7w QviWFJTGKaUwELXZO4Aqt3COqbTRsn8DxonCKfVE73yzwAqM0nC2iJZawkRE1gOHsttx lbQluaMbFSsQqhmBOhMzwY6xpeFUf+nc4dJvtpiEF/plDtB9VFnFBkRbdQjkyXv89Vgp j0TqRXx493Pg3Gkqu5kqjkwSazRKTFTFByGgRFj8xAeE9x0f2EjfjdpRaeD5IOwbgE0J 65JAAikhb5+eq6+kicKfheRobr11Q+kaoynbnT/G7dIqBxclPGfsIdjt991CnKYBNREg RSzg== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr105204874vco.22.1358245978574; Tue, 15 Jan 2013 02:32:58 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 02:32:58 -0800 (PST) Date: Tue, 15 Jan 2013 11:32:58 +0100 Message-ID: From: Abdussalam Baryun To: "Timothy J. Salo" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 10:33:00 -0000 Was: Sub:Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) http://www.ietf.org/mail-archive/web/manet/current/msg14618.html ++++++++++++++++++++++++++++++++++++++++++++++++ Sub:Router's Implemetation and Running Code Hi Timothy, I agree that; independent parties make different implementations following same specification. I diagree that: independent parties make independednt implementations following same specification. Therefore; Four routers with independent implementations, COULD NOT work together because their behavior are independent. Specification describe behavior of such protocol implementation. Four routers with different implementations, COULD work together if they have same specification. AB On 1/15/13, Timothy J. Salo wrote: >> Yes in your understanding it is ok, which I think any one on the list >> will think, but does thoes 4 routers with independent implementation >> can work together in same network. In my opinion if understanding >> independent the way you defined then they should work together as long >> they are following the same IETF draft specification. > > It is generally expected that "independent implementations" will > interoperate. In particular, see RFC 2026, "Internet Standards > Process", which includes the following: > > Thus, a candidate specification must be implemented and tested for > correct operation and interoperability by multiple independent > parties and utilized in increasingly demanding environments, before > it can be adopted as an Internet Standard. > > (Having said that, there appears to be a range of views as to what > "interoperable" means. For some, it means: if your implementation > conforms to the specification, it is assured of interoperating with > any other conforming implementation. For others, it seems to mean: > if you implement the same options that I do, then our implementations > will interoperate; if you implement different options, then well...) > > -tjs > ++++++ Yes in your understanding it is ok, which I think any one on the list will think, but does thoes 4 routers with independent implementation can work together in same network. In my opinion if understanding independent the way you defined then they should work together as long they are following the same IETF draft specification. In other understandning of independent, which I think that poster ment by *independent*, that they cannot work together, because they yes follow the specification but they are implemented in different architecture layers. So to say they follow the specification but not all 4 implementation use the RFC5444's assigned port. However, I may be wrong, but just making sure I understand the meaning :) AB +++ On 1/15/13, Susan Hares wrote: > AB: > > What I mean by independent implementations is that 4 different people took > the specification, and wrote the code from the specification. The four > people did not share their code with each other. > > This is different than 4 people taking one code base and modifying it. > > Sue > > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun at gmail.com] > Sent: Monday, January 14, 2013 1:45 PM > To: Jiazi Yi > Cc: Susan Hares; manet at ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence numbers > (warning long post) > > On 1/14/13, Jiazi Yi wrote: >> For LOADng, which make use of this sequence number rotation, has at >> least 4 independent implementations. As far as I can see, I didn't notice > any issue. >> > > Do you mean four different implementation or independent implementation. I > understand the independent cannot work together (not interoperable), or am > I > wrong, > > AB > > From yi.jiazi@gmail.com Tue Jan 15 02:45:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6F21F8804 for ; Tue, 15 Jan 2013 02:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDtWcBEOzYUu for ; Tue, 15 Jan 2013 02:45:23 -0800 (PST) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id 515DE21F87F7 for ; Tue, 15 Jan 2013 02:45:23 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id j4so2481937bkw.6 for ; Tue, 15 Jan 2013 02:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=DLWAWwhbuxmHHuj/IRn3WC5lhT/XND17xvSeg8xlgQc=; b=wFPVRGWER53A7vnojzdNdWKKmhKaMsW4zTYD7/vjPFknN0n3rHQ+0rOnno+D84kzD5 MOiFw/xRhxz2PFNuw31QzIYoI1gSjjwxJXQM86vsr6gIk9F1r0UNFrWgN2sKZlWD/lTa YddG9rd1Thz/DvgQcU6N9lzYlMtnw8rmSg3HwVmZgWMiWn7VJfJAIf2R5AFh/7FJe0Sr 2W3cN5kA6y3sZ9y95KVCRdR2EiZini6UCF/XnQSIvx9h46Mn+oTIR5ptnTAqQOgAMA6l d5QrLqdG4QX7ZZTYkh0X/33NpLWJlt2beDSkAyI1brF/szOqJPvaTQehI1b31iYuroR3 +bOw== X-Received: by 10.204.15.203 with SMTP id l11mr39615924bka.74.1358246722145; Tue, 15 Jan 2013 02:45:22 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id o9sm12262312bko.15.2013.01.15.02.45.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 02:45:21 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Tue, 15 Jan 2013 11:45:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> <005d01cdf2c0$330e4bf0$992ae3d0$@ndzh.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 10:45:24 -0000 RFC 2026: In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. Jiazi On Jan 15, 2013, at 9:51 AM, Abdussalam Baryun = wrote: > Hi Sue, >=20 > Yes in your understanding it is ok, which I think any one on the list > will think, but does thoes 4 routers with independent implementation > can work together in same network. In my opinion if understanding > independent the way you defined then they should work together as long > they are following the same IETF draft specification. >=20 > In other understandning of independent, which I think that poster ment > by *independent*, that they cannot work together, because they yes > follow the specification but they are implemented in different > architecture layers. So to say they follow the specification but not > all 4 implementation use the RFC5444's assigned port. >=20 > However, I may be wrong, but just making sure I understand the meaning = :) >=20 > AB >=20 > On 1/15/13, Susan Hares wrote: >> AB: >>=20 >> What I mean by independent implementations is that 4 different people = took >> the specification, and wrote the code from the specification. The = four >> people did not share their code with each other. >>=20 >> This is different than 4 people taking one code base and modifying = it. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: Monday, January 14, 2013 1:45 PM >> To: Jiazi Yi >> Cc: Susan Hares; manet@ietf.org >> Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers >> (warning long post) >>=20 >> On 1/14/13, Jiazi Yi wrote: >>> For LOADng, which make use of this sequence number rotation, has at >>> least 4 independent implementations. As far as I can see, I didn't = notice >> any issue. >>>=20 >>=20 >> Do you mean four different implementation or independent = implementation. I >> understand the independent cannot work together (not interoperable), = or am >> I >> wrong, >>=20 >> AB >>=20 >>=20 From abdussalambaryun@gmail.com Tue Jan 15 03:14:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718D221F870E for ; Tue, 15 Jan 2013 03:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8jV8cbZIX9D for ; Tue, 15 Jan 2013 03:14:09 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCE421F8552 for ; Tue, 15 Jan 2013 03:14:09 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so4036668vbi.8 for ; Tue, 15 Jan 2013 03:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XIGOGpARlhYn26Z2o2c1IPc11VpuuOPT1N1Qu2N06z4=; b=TbpISyr+u2SpflyI/jXnq4MMayJ0+NsSra/1qlEgMzZ18K9OkWywEH4gtmR4GxEF5w f+APWsPgVRyzgAk4skuvEKyBVvEKItfieWolu6QNmzOe7g6P935wCJSBGTUolte9Z6+O eTXV0DUocw7ghWfScw6TGvQzYyktexqgs4/0hqEjAlCGBFX3/ticCWrJrZRA5aBp9XW9 mrQihP0IY+IcmNq/GygJXo8vBdgONqmBi1ST9gC8aOQQB0b5u9z1ATDT1jlAa5wAEf2S IQh3JheCheNuR1+IPO7UjrO5mZqklyrUwWvUx7IhVBs+hEz2WlaRkj8V7G9MTjh40buA N+Wg== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr90443902vdc.125.1358248448518; Tue, 15 Jan 2013 03:14:08 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 03:14:08 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 12:14:08 +0100 Message-ID: From: Abdussalam Baryun To: "Timothy J. Salo" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:14:10 -0000 As you agree with RFC2026, I can understand you mean that the 4 implementation you refered to previously are interoperable, please confirm, and that they may work together, AB On 1/15/13, Jiazi Yi wrote: > RFC 2026: > > In general, an Internet Standard is a specification that is stable > and well-understood, is technically competent, has multiple, > independent, and interoperable implementations with substantial > operational experience, enjoys significant public support, and is > recognizably useful in some or all parts of the Internet. > > Jiazi > On 1/15/13, Abdussalam Baryun wrote: > Was: Sub:Re: [manet] Hares technical question 1: Design of sequence > numbers (warning long post) > http://www.ietf.org/mail-archive/web/manet/current/msg14618.html > ++++++++++++++++++++++++++++++++++++++++++++++++ > > Sub:Router's Implemetation and Running Code > > Hi Timothy, > > I agree that; independent parties make different implementations > following same specification. > > I diagree that: independent parties make independednt implementations > following same specification. > > Therefore; > Four routers with independent implementations, COULD NOT work together > because their behavior are independent. Specification describe > behavior of such protocol implementation. > > Four routers with different implementations, COULD work together if > they have same specification. > > AB > > On 1/15/13, Timothy J. Salo wrote: >>> Yes in your understanding it is ok, which I think any one on the list >>> will think, but does thoes 4 routers with independent implementation >>> can work together in same network. In my opinion if understanding >>> independent the way you defined then they should work together as long >>> they are following the same IETF draft specification. >> >> It is generally expected that "independent implementations" will >> interoperate. In particular, see RFC 2026, "Internet Standards >> Process", which includes the following: >> >> Thus, a candidate specification must be implemented and tested for >> correct operation and interoperability by multiple independent >> parties and utilized in increasingly demanding environments, before >> it can be adopted as an Internet Standard. >> >> (Having said that, there appears to be a range of views as to what >> "interoperable" means. For some, it means: if your implementation >> conforms to the specification, it is assured of interoperating with >> any other conforming implementation. For others, it seems to mean: >> if you implement the same options that I do, then our implementations >> will interoperate; if you implement different options, then well...) >> >> -tjs >> > ++++++ > Yes in your understanding it is ok, which I think any one on the list > will think, but does thoes 4 routers with independent implementation > can work together in same network. In my opinion if understanding > independent the way you defined then they should work together as long > they are following the same IETF draft specification. > > In other understandning of independent, which I think that poster ment > by *independent*, that they cannot work together, because they yes > follow the specification but they are implemented in different > architecture layers. So to say they follow the specification but not > all 4 implementation use the RFC5444's assigned port. > > However, I may be wrong, but just making sure I understand the meaning :) > > AB > +++ > On 1/15/13, Susan Hares wrote: >> AB: >> >> What I mean by independent implementations is that 4 different people >> took >> the specification, and wrote the code from the specification. The four >> people did not share their code with each other. >> >> This is different than 4 people taking one code base and modifying it. >> >> Sue >> >> -----Original Message----- >> From: Abdussalam Baryun [mailto:abdussalambaryun at gmail.com] >> Sent: Monday, January 14, 2013 1:45 PM >> To: Jiazi Yi >> Cc: Susan Hares; manet at ietf.org >> Subject: Re: [manet] Hares technical question 1: Design of sequence >> numbers >> (warning long post) >> >> On 1/14/13, Jiazi Yi wrote: >>> For LOADng, which make use of this sequence number rotation, has at >>> least 4 independent implementations. As far as I can see, I didn't >>> notice >> any issue. >>> >> >> Do you mean four different implementation or independent implementation. >> I >> understand the independent cannot work together (not interoperable), or >> am >> I >> wrong, >> >> AB >> >> > From henning.rogge@fkie.fraunhofer.de Tue Jan 15 03:25:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AEB21F87F3 for ; Tue, 15 Jan 2013 03:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA+KJDG1ItVx for ; Tue, 15 Jan 2013 03:25:57 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A558F21F87C8 for ; Tue, 15 Jan 2013 03:25:56 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv4eS-0003ew-1G for manet@ietf.org; Tue, 15 Jan 2013 12:25:56 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv4eR-0006v3-Uq for manet@ietf.org; Tue, 15 Jan 2013 12:25:55 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 12:25:55 +0100 Message-ID: <50F53CC2.6040205@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 12:25:54 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000602050206030508000603" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16493/Tue Jan 15 06:43:54 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b023bd6aafd0ed920562fab22193c372 Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:25:57 -0000 --------------ms000602050206030508000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: > As you agree with RFC2026, I can understand you mean that the 4 > implementation you refered to previously are interoperable, please > confirm, and that they may work together, Maybe this will answer your question? I think this document was already=20 mentioned on this list. http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-04 Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000602050206030508000603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUxMTI1NTRaMCMGCSqGSIb3DQEJBDEWBBTbN2TR9AIBzhog2kxW6xMUit5UjDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAAc1YmOl50cIOv0ou7dADt6dTgEsb17LhmyIAbqN/esIl kY54a50RJD88JIOmLzJ1Ie8bV0qb1iQ9jtcm7FqGziwxjl6CfBWWOxvCxCF/SltLfTWOqV2B hOTdf0bmPi9pyuDC4uT67BHZ7HQH19cZocAH3ZvMDnR6zfwrVJBTK/ulMXx4JW03JHMAp2jQ SK4PkVBMC84DOnqh/vcg75oHB3FBHH4BCe2j4/Hd+siCO68AQlq1NbzTUo8v6PLSlTCezbPB Om756QUylzBQz04UOGFS+dV3hymLXFQF+Vo3/LLeygZfx6BtEma26oAlLGUoXuJVBl634Dcv Iu+Ijky+YgAAAAAAAA== --------------ms000602050206030508000603-- From abdussalambaryun@gmail.com Tue Jan 15 03:26:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08721F87F3 for ; Tue, 15 Jan 2013 03:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv3FEjQ5wMNR for ; Tue, 15 Jan 2013 03:26:52 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90AA421F87D4 for ; Tue, 15 Jan 2013 03:26:52 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4572310vbb.17 for ; Tue, 15 Jan 2013 03:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7HyZpP/aYlcHpLrcJaGPt7RAy/LjG/J/NLD5OsvVsVs=; b=c7Hc481iRQcJ4a+rYNaORAx13P9OnZWosNsCd6tofM5ZZmJ4MJXPFHb2CunaLZfl3Z 4zFSyjzI2F9yx8QOZY7CI7y0zq/s5q/d6TWe3AnBcEsbv7ltyn1GaoZoAMcO38opnmiL HHQiZ9Q9OJ9FOrmKzArIzfXQLp4I8UkosD+3tlY2cH3RRw400ltiYdAV/9Omp+naaCIZ GKLzHhPF6WTNO5B1EP9Df1Ngsbah/u9Qm35xCl3QXsv0oL8WbzXBsGg6bsSEYy0j4ZR3 ZZDRluLRe/yM/V+fdD1vTyE3YPMSL5I8/Um1wcD3MnlsJf3vP1Jq0W6apyKE0SYBuAgT ELmg== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr90467841vdc.125.1358249212017; Tue, 15 Jan 2013 03:26:52 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 03:26:51 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 12:26:51 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:26:53 -0000 RFC2026 >> In general, an Internet Standard is a specification that is stable >> and well-understood, is technically competent, has multiple, >> independent, and interoperable implementations with substantial >> operational experience, enjoys significant public support, and is >> recognizably useful in some or all parts of the Internet. Ok, I agree with the text; that IETF standards need to be *multiple+ independent+interoperable* implementations. I agree that Standards and Specifications in IETF, implementations SHOULD be interoperable if independently implemented. I disagree that one standard have independednt implementations, without mentioning interoperability. It should be tested after all by the community, AB From abdussalambaryun@gmail.com Tue Jan 15 03:34:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BA521F88AC for ; Tue, 15 Jan 2013 03:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvGIjype1gbQ for ; Tue, 15 Jan 2013 03:34:59 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id DF68321F863B for ; Tue, 15 Jan 2013 03:34:58 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id p16so4498336vcq.25 for ; Tue, 15 Jan 2013 03:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MRKF++Q9tGL/XJcL7YHlkGs8Qi3H8KOX2cYbIAZLr0U=; b=m258V4XhyYXG4LALzqY5dUDK989kvmDvhRH2goUMrWNVkeUhXoJ2EGW78Q3O2jo8tQ nmAglsNTSTu7Z0l1dm5Yi+OBxRkNk+LF+2LmMbdwrcXFT17AsBJzlA9P15iEiWtfyISz +fkgl7ZhYsn1ybO+/A5Aflt8t7EvsnVQ0fXL7l1yklZC0hQ5YlE2+0Fe0zSfLnqNLdTF 5iO5DZGdbQC6KWBH0SYrmGhTWVRrFJ1ZbKp7/8/5pULxTHtmBRRJqBnYjMq+iNP7Ds2R AD0+/tf4b9G3Te7RKog9AOdNVEdyYGVN14BhKZGF6IhqRUJktEwNmuvSNJhAuJV6csUE DoSQ== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr105283633vcq.31.1358249698052; Tue, 15 Jan 2013 03:34:58 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 03:34:57 -0800 (PST) In-Reply-To: <50F53CC2.6040205@fkie.fraunhofer.de> References: <50F53CC2.6040205@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 12:34:57 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:34:59 -0000 Hi Henning, thanks alot, but I think the tests reported by the doc is only for one implementation, not all 4 LOADng implementations, however, I will contact the authors of the doc, thanks, AB On 1/15/13, Henning Rogge wrote: > On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: >> As you agree with RFC2026, I can understand you mean that the 4 >> implementation you refered to previously are interoperable, please >> confirm, and that they may work together, > > Maybe this will answer your question? I think this document was already > mentioned on this list. > > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-04 > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From henning.rogge@fkie.fraunhofer.de Tue Jan 15 03:37:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056A521F848B for ; Tue, 15 Jan 2013 03:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoOvQWAZKFqY for ; Tue, 15 Jan 2013 03:37:43 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2301121F8442 for ; Tue, 15 Jan 2013 03:37:43 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv4pq-0007jZ-GG; Tue, 15 Jan 2013 12:37:42 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv4pq-0007ED-DY; Tue, 15 Jan 2013 12:37:42 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 12:37:42 +0100 Message-ID: <50F53F85.7070501@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 12:37:41 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50F53CC2.6040205@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020900040308010305050804" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16493/Tue Jan 15 06:43:54 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 44205366898805df1de72924aa95b600 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:37:44 -0000 --------------ms020900040308010305050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 12:34 PM, Abdussalam Baryun wrote: > Hi Henning, > > thanks alot, but I think the tests reported by the doc is only for one > implementation, not all 4 LOADng implementations, however, I will > contact the authors of the doc, thanks, I believe that you should read the document before stating something=20 like this... *facepalm* Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020900040308010305050804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUxMTM3NDFaMCMGCSqGSIb3DQEJBDEWBBTCmsPaufhgYM1ZC2or2gYCGPiYujBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAYHkVFwEXrQZ4yMT5skAZzA+i5jjZA1I5SqSw62ZO8Fx2 5kwBxOPiXWBzj52YXOCThH1SawKX3HGgcm/RQAr8+RTso749GIQ2rKJOoh4P/4RvTI0y66Aj FnrS39HwEBo6UzJ8m1aLQiMhMA/cfVDYp6nMbTT4gOAx6VtUtd0hCCjo6L3BImRHjcp2NfuQ 7f7SuMkgdLHPCcQWZhpY0eVJ0hgsv8pyqTqZeHe7lK65ORTMzzjKlAqfWuSg5xsmQ5QmJpVn HtR4KnnDcwe11eVhQWJ2UvUMcas5gA81aY/OaAmrVW7N3i/GieWUPcHC4EOtvkz1wyRBbeSt Tf50QF5/LAAAAAAAAA== --------------ms020900040308010305050804-- From Chris.Dearlove@baesystems.com Tue Jan 15 05:22:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4D21F86CD for ; Tue, 15 Jan 2013 05:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npJqQihf6A11 for ; Tue, 15 Jan 2013 05:22:22 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 52BF721F874C for ; Tue, 15 Jan 2013 05:22:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="255179177" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 15 Jan 2013 13:22:21 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0FDMKDY014922 for ; Tue, 15 Jan 2013 13:22:20 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6955"; a="3376035" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 15 Jan 2013 13:22:20 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Tue, 15 Jan 2013 13:22:20 +0000 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , Ulrich Herberg Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIA== Date: Tue, 15 Jan 2013 13:22:19 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> In-Reply-To: <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:22:23 -0000 To my mind, a critical question is whether an RREQ or an RREP might, at som= e point, carry more than one address in what is the main address category. Could an RREQ carry more than one address "I'm looking for A and/or B"? (an= d/or, as I could see either being a possibility). Could an RREP carry more than one address - either "you asked for A, I am A= . I'm also B, C and D" or with IRREPs "I also route to B, C and D". This sort of information could be flagged with TLVs. Positionally it's much= harder - especially if we may want to add such cases later. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=C2=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= homas Heide Clausen Sent: 11 January 2013 16:50 To: Ulrich Herberg Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- In complete agreement with Ulrich here.=20 Associating semantics to ordering of TLVs or addresses in 5444 removes the = ability for generic parsers and generators. That would be a very unfortunat= e design, given that 5444 was designed exactly to be generic. Thomas Sent from my iPad On 11 janv. 2013, at 08:25, Ulrich Herberg wrote: > I agree with Henning. A protocol using RFC5444 should not mandate a certa= in order or a split into address blocks for the reasons Henning mentioned. = The RFC5444 parser/generator can be independent of the protocol that uses i= t (in my LOADng code that's the case), and used by several protocol impleme= ntations and extensions concurrently. The protocols and extensions may not = necessarily have the information about positions or split into address bloc= ks. >=20 > In LOADng, no such knowledge is required. >=20 > Regards > Ulrich >=20 > On Jan 10, 2013, at 23:03, Henning Rogge wrote: >=20 >> On 01/10/2013 08:42 AM, Charles E. Perkins wrote: >>> Hello Henning, >>>=20 >>> I'll put the issue on the Issue Tracker tomorrow. >>>=20 >>> However, there have been many protocols using positional information >>> for lists (of addresses, etc) without impairment of extensibility. >>> This is especially true when extensions go at the end. Do you have >>> any particular example in mind where RFC 5444 somehow creates >>> a problem with this? >>=20 >> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because = I can just add whatever I want to the protocol message, as long as I use ne= w TLVs. >>=20 >> New addresses? No problem, regardless on the position. >>=20 >> New TLVs on existing addresses? No problem too. >>=20 >> Why use a pure TLV format if we put parts of the information into the or= der and structure of the format and do NOT use TLVs for it? >>=20 >> The restriction of the order of addresses and the mandatory split into m= ultiple address blocks is also a problem for address compression. The order= and split have a huge influence on the compression efficiency, demanding a= specific split/order will make AODVv2 messages larger in some cases. >>=20 >> Henning Rogge >>=20 >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Jan 15 05:36:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3521F88C7 for ; Tue, 15 Jan 2013 05:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ci97bnMP5OH for ; Tue, 15 Jan 2013 05:36:44 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A3D1D21F87D2 for ; Tue, 15 Jan 2013 05:36:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208,217";a="300570453" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 15 Jan 2013 13:36:42 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0FDag9V016898 for ; Tue, 15 Jan 2013 13:36:42 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6955"; a="3600748" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 15 Jan 2013 13:36:41 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Tue, 15 Jan 2013 13:36:42 +0000 From: "Dearlove, Christopher (UK)" To: Susan Hares , "manet@ietf.org" Thread-Topic: [manet] Hares Technical Question 2: order of address in TLV Thread-Index: Ac3yFhOratnXSvfpSO6Gc0VvxiKSKwBDfTTw Date: Tue, 15 Jan 2013 13:36:42 +0000 Message-ID: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> In-Reply-To: <001201cdf216$1cbd6930$56383b90$@ndzh.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FF0552GLKXM0002VGREEN_" MIME-Version: 1.0 Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:36:47 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FF0552GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Note that addresses are not in TLVs. Addresses are in address blocks. Each address block has an associated TLV block The way in which 5444 is used by OLSRv2 and NHDP, and which various people think should be at least advised for its use, is that an address in an address block has no meaning in and of itself. It''s only when a TV (or TLVs) is/are associated with it that it gains meaning. That's even a broader consideration than not gaining any information due to position. In OLSRv2, in particular, most addresses in a TC message are advertised neighbours. It would have been possible (and in fact was the case in earlier drafts) that any unlabelled (by a TLV) address was so associated. But instead a specific TLV was added. Technically a small overhead, but it freed up the possibility of later adding additional addresses that meant something totally new (with their own TLV for that meaning). Otherwise all added addresses would have to be advertised neighbours. (Or we go down an even more complicated route of assigning a meaning to "no TLV", and then start asking about distinctions between addresses and address objects.) What might such an address mean? An obvious possibility is something local (which actually also once was present, but removed). I don't think any such advice would cause replacement of 5444. If published in an RFC it could be informational (this is what the authors intended) or BCDP (this is how you should use 5444 - or possibly this is how you should use 5444 in the 5498 context). -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Susan Hares Sent: 14 January 2013 05:15 To: manet@ietf.org Subject: [manet] Hares Technical Question 2: order of address in TLV *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Technical issue 2 - order of address in TLV | AddrTLV[1] | the first item in AddrTLV | | AddrTLV[N] | the Nth item in AddrTLV | | AddrTLV[OrigNode] | AddrTLV[1] | | AddrTLV[TargNode] | AddrTLV[2] | Questions: 1. Is this sequence normal for the RFC5444? 2. Is it specified in RFC5444 as a requirement? 3. Why does Henning Rogge consider it bad? He seems to imply that he wants the TLVs numbering to set the order. 3a. Do I understand the format? 3a. Why does it matter? The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) seems come second and provide potential better paths. It would make processing sense to grab the first block to process to get a basic connection (before the nodes move on), and then fine tune). It could be considered "make before you tune it" (a variant of the make before break concept). BGP implementation often try to pack things in the packet so the most important processing comes first. Caveat: I am trying to catch up with your excellent work. If there is previous mail discussion, please let me know. I'll go read it so I can ask better questions. Sue Hares ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FF0552GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Note that addresses are not in TLVs. Addresses are in address blocks. Each address block has an associated TLV block

The way in which 5444 is used by OLSRv2 and NHDP, and which various people think should be at least advised for its use, is that an address in an address block has no meaning in and of itself. It''s only when a TV (or TLVs) is/are associated with it that it gains meaning. That's even a broader consideration than not gaining any information due to position.

In OLSRv2, in particular, most addresses in a TC message are advertised neighbours. It would have been possible (and in fact was the case in earlier drafts) that any unlabelled (by a TLV) address was so associated. But instead a specific TLV was added. Technically a small overhead, but it freed up the possibility of later adding additional addresses that meant something totally new (with their own TLV for that meaning). Otherwise all added addresses would have to be advertised neighbours. (Or we go down an even more complicated route of assigning a meaning to "no TLV", and then start asking about distinctions between addresses and address objects.) What might such an address mean? An obvious possibility is something local (which actually also once was present, but removed).

I don't think any such advice would cause replacement of 5444. If published in an RFC it could be informational (this is what the authors intended) or BCDP (this is how you should use 5444 - or possibly this is how you should use 5444 in the 5498 context).

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Susan Hares
Sent: 14 January 2013 05:15
To: manet@ietf.org
Subject: [manet] Hares Technical Question 2: order of address in TLV

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Technical issue 2 – order of address in TLV

 

|     AddrTLV[1]     |       the first item in AddrTLV           |

|     AddrTLV[N]     |          the Nth item in AddrTLV          |

|  AddrTLV[OrigNode] |                 AddrTLV[1]                |

|  AddrTLV[TargNode] |                 AddrTLV[2]                |

 

 

Questions:

 

1.  Is this sequence normal for the RFC5444? 

2.  Is it specified in RFC5444 as a requirement?

3.  Why does Henning Rogge consider it bad?

 

    He seems to imply that he wants the TLVs numbering to set the order.

 

   3a. Do I understand the format?

 

   3a. Why does it matter? 

 

The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) seems come second and provide potential better paths. It would make processing sense to grab the first block to process to get a basic connection (before the nodes move on), and then fine tune).  It could be considered “make before you tune it”  (a variant of the make before break concept).

 

BGP implementation often try to pack things in the packet so the most important processing comes first.

 

Caveat:  I am trying to catch up with your excellent work. If there is previous mail discussion, please let me know.  I’ll go read it so I can ask better questions.

 

Sue Hares

 


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FF0552GLKXM0002VGREEN_-- From Chris.Dearlove@baesystems.com Tue Jan 15 05:39:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0312821F86CB for ; Tue, 15 Jan 2013 05:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBjxn+ETY-hZ for ; Tue, 15 Jan 2013 05:39:02 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEB21F86CA for ; Tue, 15 Jan 2013 05:39:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="255184908" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 15 Jan 2013 13:39:01 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0FDd07i026541 for ; Tue, 15 Jan 2013 13:39:00 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6955"; a="3378980" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 15 Jan 2013 13:39:00 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Tue, 15 Jan 2013 13:39:00 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Susan Hares Thread-Topic: [manet] Hares Technical Issue 4 - GTSM Thread-Index: Ac3yG1ooffsJJST5TemjEv3rrPLmmQADjhmAAA5gSoAAAFw9AAAwPTZg Date: Tue, 15 Jan 2013 13:38:59 +0000 Message-ID: References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> <012801cdf263$14855960$3d900c20$@ndzh.com> <50F417E4.8070304@fkie.fraunhofer.de> In-Reply-To: <50F417E4.8070304@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:39:03 -0000 I think perhaps the correct place is actually 5498 rather than 5444. (5498 = mandates - on the manet port/protocol - that which 5444 provides as a propo= sed usage.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 14 January 2013 14:36 To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM On 01/14/2013 03:26 PM, Susan Hares wrote: > Henning: > > Again, thank you for aiding my understanding. > > Do I understand from this message that RFC5444 should be the protocol > running GTSM? Yes, I think GTSM is a security consideration (and option) for RFC5444. So AODVv2 could suggest using it for RFC5444, but I don't think its the=20 place to mandate its usage. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Jan 15 05:42:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343C621F86CB for ; Tue, 15 Jan 2013 05:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+cGh8HKZ6dv for ; Tue, 15 Jan 2013 05:42:32 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1958D21F86CA for ; Tue, 15 Jan 2013 05:42:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="300572954" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 15 Jan 2013 13:42:31 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0FDgUpY025634 for ; Tue, 15 Jan 2013 13:42:30 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6955"; a="3601867" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 15 Jan 2013 13:42:30 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Tue, 15 Jan 2013 13:42:30 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Susan Hares Thread-Topic: [manet] Hares technical question 1: Design of sequence numbers (warning long post) Thread-Index: AQHN8mYfHD3wyECBvE2iDXgoY9GW3ZhKZs8A Date: Tue, 15 Jan 2013 13:42:30 +0000 Message-ID: References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> In-Reply-To: <50F41A84.1080904@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:42:33 -0000 The case S1 and S2 differ by MAXVALUE / 2 is indeterminate. There's actuall= y a technical problem is you define it, as then A can supersede B can super= sede A. You're probably better off keeping the older/newer item as determin= ed by order of reception, not serial number. OLSRv2 says this case is up to= you. What it doesn't say is that if you ever see it smething somewhere is = broken and is likely to make a mess of things. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 14 January 2013 14:48 To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers= (warning long post) Sorry for not the bad answer to your first mail. See explanation below... On 01/14/2013 03:19 PM, Susan Hares wrote: > Henning: > > Thank you for the quick response. Below I have the text sections from > > http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt > > How should I interpret this text? Your comment is > > -1 (0xFFFF), 0, 1 > > How does it work? > > Let us assume S1 rotates through MAX_VALUE > (0xFFFF, 0, 1) , and S2 stays at 0xCFFF. > > The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF > Step 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF > S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 > > Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore s1 = is > S2 > Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > 0x3FFF > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case fo= llows >> The sequence number S1 is said to be "greater than" (denoted '>') >> the sequence number S2 if: >> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE/2 If this formula is "true", S1 is considered larger than S2. If this formula is "false", S1 is considered to be smaller than S2. Its a single boolean formula, no "two cases". @Ulrich Herberg: maybe the formula could be presented like this to make it more clear? (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE/2) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Tue Jan 15 05:48:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564A21F85E8 for ; Tue, 15 Jan 2013 05:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-1GR4Ix9zzO for ; Tue, 15 Jan 2013 05:48:29 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 699B921F8555 for ; Tue, 15 Jan 2013 05:48:28 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tv6sN-0000oj-Jv; Tue, 15 Jan 2013 14:48:27 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tv6sN-0002Nx-HC; Tue, 15 Jan 2013 14:48:27 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 14:48:27 +0100 Message-ID: <50F55E26.4000207@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 14:48:22 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> <012801cdf263$14855960$3d900c20$@ndzh.com> <50F417E4.8070304@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040802090103060800080909" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16494/Tue Jan 15 12:44:10 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b023bd6aafd0ed920562fab22193c372 Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:48:29 -0000 --------------ms040802090103060800080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/15/2013 02:38 PM, Dearlove, Christopher (UK) wrote: > I think perhaps the correct place is actually 5498 rather than 5444. > (5498 mandates - on the manet port/protocol - that which 5444 > provides as a proposed usage.) That sounds good too. An alternative would have been to mention the TTL security option in RFC = 6622. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040802090103060800080909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUxMzQ4MjVaMCMGCSqGSIb3DQEJBDEWBBSHBIbAM8TubsrLzAVmFjQdMSHmGzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAZ1yoSfDGWoe2e/3Zce1S3X2vDzVYWGibLjiF/SKwjMjS ZlwhwdyElvLR/sCnzOfmh7yK5jfVUzdHv2PV7Xgw68Kx/gQxtQsnjiOADn7txt+DZewOoeUT SfjXnKHFllJbNWmpWAU3Py3GQhI8stkzA547bOAgv6n6tuSGRQaTTq0J6Xqj5b6kDcpK1btK lMpqXxgJIOe95Lo78d5FndWAiaelwYIs118Y8PWLB6BPdlB3IIHJZgkA+VUi4MI55MKnt24R jtRnKEPKfJGvcqEXUvQda7Tml0C49uzf76LrjnJSWpnjtJFv1IGjzcKqCrVj58lXk1DSmE3x eVdnOfpPKQAAAAAAAA== --------------ms040802090103060800080909-- From abdussalambaryun@gmail.com Tue Jan 15 05:52:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FCF21F88A6 for ; Tue, 15 Jan 2013 05:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqAOKh2lELnU for ; Tue, 15 Jan 2013 05:52:13 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 996E521F85E8 for ; Tue, 15 Jan 2013 05:52:13 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id l6so113132vcl.23 for ; Tue, 15 Jan 2013 05:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zhdEcAjU8FBswmKjBhOskZHjKrdQhSAlYsB3gRnCk9k=; b=cf3l836I+h8VVHJPdxNgdv30QBQd6OKp+6DOBipyhqji8vHdVtaZpdfirom+nIBh17 CuELpl2duO7ORheTuzhpgzG1s7FJCmWpoH/A0SxDG3o1ocANOtntoL6PFjdaxVhgxZRi a5N8zaWVd4wlUGIjXWDIfZCRvGs6Mcii/j2nTlZvStoyAep48yQh6jyu9agWbRy/HOYs B6wBQ04pEL8Rg5LhKS9zP2Arl3AWv8U/gY/8wpcyUTVUe4YG4awtmeNamH3G0/FntKK6 V6LCyJ8q7kvZ+N6hc5lyLdTi4lSHlgstkeZTf6z/C+Y9gGd49XiiJJYxmIJ59tDOQ8r2 rJtw== MIME-Version: 1.0 Received: by 10.52.27.50 with SMTP id q18mr92791178vdg.20.1358257932935; Tue, 15 Jan 2013 05:52:12 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 05:52:12 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> Date: Tue, 15 Jan 2013 14:52:12 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:52:14 -0000 Hi Chris, I agree that your right that it will be harder if want to add such cases later. However both cases of RREP and RREQ of more than one address reporting are done by address blocks in dymo, do you think there is a disadvantage? AB On 1/15/13, Dearlove, Christopher (UK) wrot= e: > To my mind, a critical question is whether an RREQ or an RREP might, at s= ome > point, carry more than one address in what is the main address category. > > Could an RREQ carry more than one address "I'm looking for A and/or B"? > (and/or, as I could see either being a possibility). > Could an RREP carry more than one address - either "you asked for A, I am= A. > I'm also B, C and D" or with IRREPs "I also route to B, C and D". > > This sort of information could be flagged with TLVs. Positionally it's mu= ch > harder - especially if we may want to add such cases later. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Thomas Heide Clausen > Sent: 11 January 2013 16:50 > To: Ulrich Herberg > Cc: manet@ietf.org > Subject: Re: [manet] Notifications from the IETF tools Issue Tracker > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > In complete agreement with Ulrich here. > > Associating semantics to ordering of TLVs or addresses in 5444 removes th= e > ability for generic parsers and generators. That would be a very unfortun= ate > design, given that 5444 was designed exactly to be generic. > > Thomas > > Sent from my iPad > > On 11 janv. 2013, at 08:25, Ulrich Herberg wrote: > >> I agree with Henning. A protocol using RFC5444 should not mandate a >> certain order or a split into address blocks for the reasons Henning >> mentioned. The RFC5444 parser/generator can be independent of the protoc= ol >> that uses it (in my LOADng code that's the case), and used by several >> protocol implementations and extensions concurrently. The protocols and >> extensions may not necessarily have the information about positions or >> split into address blocks. >> >> In LOADng, no such knowledge is required. >> >> Regards >> Ulrich >> >> On Jan 10, 2013, at 23:03, Henning Rogge >> wrote: >> >>> On 01/10/2013 08:42 AM, Charles E. Perkins wrote: >>>> Hello Henning, >>>> >>>> I'll put the issue on the Issue Tracker tomorrow. >>>> >>>> However, there have been many protocols using positional information >>>> for lists (of addresses, etc) without impairment of extensibility. >>>> This is especially true when extensions go at the end. Do you have >>>> any particular example in mind where RFC 5444 somehow creates >>>> a problem with this? >>> >>> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol because= I >>> can just add whatever I want to the protocol message, as long as I use >>> new TLVs. >>> >>> New addresses? No problem, regardless on the position. >>> >>> New TLVs on existing addresses? No problem too. >>> >>> Why use a pure TLV format if we put parts of the information into the >>> order and structure of the format and do NOT use TLVs for it? >>> >>> The restriction of the order of addresses and the mandatory split into >>> multiple address blocks is also a problem for address compression. The >>> order and split have a huge influence on the compression efficiency, >>> demanding a specific split/order will make AODVv2 messages larger in so= me >>> cases. >>> >>> Henning Rogge >>> >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Jan 15 06:01:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4397C21F871C for ; Tue, 15 Jan 2013 06:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phRst4M416CY for ; Tue, 15 Jan 2013 06:01:14 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 069AE21F86B8 for ; Tue, 15 Jan 2013 06:01:11 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id l6so121730vcl.37 for ; Tue, 15 Jan 2013 06:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qn2SYYV6QhRoF8GM36MYcgKjBibA2kImEWT2pwVp328=; b=IJ4sB+BUNIkZZn6fp4R447AKPrxDwD4gmkglwBa4klBBGNyEC0vSnGf6i1FFyQ7DKh KxhrxsNt2I2iIkLdiT7s3c1tFeYk3dxMA7qHdXgbFynYAc6fhDEwjjoB4E73oTGeTCVU aRKXfNq43781HG6s6tRY7KI/1UJ3xPqvdV8u2eFGxWnXcC5dpL00YmDXCGsG6d6gx8Xc n5tAVs4LsihSSxy3vc0hY5SDuc0scPKsMVH3DRbbem+f87f6SSZ4Fm8eqklVNeL4+LAm 3WRjJgqgJvolnjZQmrkLrYLjSGPgAl87F8hH45SiUwiSuRMN/RnfM1Br124OFr0d7Cqf u4PA== MIME-Version: 1.0 Received: by 10.220.247.136 with SMTP id mc8mr26879271vcb.44.1358258471460; Tue, 15 Jan 2013 06:01:11 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 06:01:11 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> Date: Tue, 15 Jan 2013 15:01:11 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:01:15 -0000 On 1/15/13, Dearlove, Christopher (UK) wrote: > I don't think any such advice would cause replacement of 5444. If published > in an RFC it could be informational (this is what the authors intended) or > BCDP (this is how you should use 5444 - or possibly this is how you should > use 5444 in the 5498 context). not replacing RFC5444, but I like the suggestion as informational or maybe a best practice doc for using 5444, AB > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Susan Hares > Sent: 14 January 2013 05:15 > To: manet@ietf.org > Subject: [manet] Hares Technical Question 2: order of address in TLV > > > *** WARNING *** > This message originates from outside our organisation, either from an > external partner or the internet. > Keep this in mind if you answer this message. > Please see this > process > on how to deal with suspicious emails. > Technical issue 2 - order of address in TLV > > | AddrTLV[1] | the first item in AddrTLV | > | AddrTLV[N] | the Nth item in AddrTLV | > | AddrTLV[OrigNode] | AddrTLV[1] | > | AddrTLV[TargNode] | AddrTLV[2] | > > > Questions: > > > 1. Is this sequence normal for the RFC5444? > > 2. Is it specified in RFC5444 as a requirement? > > 3. Why does Henning Rogge consider it bad? > > > He seems to imply that he wants the TLVs numbering to set the order. > > 3a. Do I understand the format? > > 3a. Why does it matter? > > The major work of the RREQ/RREP seems to have a short block of 2 ADDRTLVs. > The longer optional addresses (a DSR sort-of source routing) seems come > second and provide potential better paths. It would make processing sense to > grab the first block to process to get a basic connection (before the nodes > move on), and then fine tune). It could be considered "make before you tune > it" (a variant of the make before break concept). > > BGP implementation often try to pack things in the packet so the most > important processing comes first. > > Caveat: I am trying to catch up with your excellent work. If there is > previous mail discussion, please let me know. I'll go read it so I can ask > better questions. > > Sue Hares > > > ******************************************************************** > 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. > ******************************************************************** > > From charliep@computer.org Tue Jan 15 08:27:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C390F21F84D1 for ; Tue, 15 Jan 2013 08:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehqVgE-Fhbmj for ; Tue, 15 Jan 2013 08:27:56 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0CA21F8479 for ; Tue, 15 Jan 2013 08:27:56 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tv9Mh-0005RH-DQ; Tue, 15 Jan 2013 11:27:55 -0500 Message-ID: <50F58387.9050600@computer.org> Date: Tue, 15 Jan 2013 08:27:51 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad868ab39d3a05aa66ea8579b5f0f48cb8db350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: "" Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:27:56 -0000 Hello Abdussalam, I meant "stability of the WG document". I think that we're pretty close to having a good specification for the base protocol functionality with a few optional behaviors that have been published in previous [manet] documents. Adding the Internet Gateway function will, if history is any guide, take a good bit longer. Regards, Charlie P. On 1/15/2013 1:45 AM, Abdussalam Baryun wrote: > Hi Charlie, > > I want to understand the subject title: stability vs gateway spec, > What you mean by stability, there was no discussion on it in thread. > Do you mean network stability? > > AB > > On 12/12/12, Charles E. Perkins wrote: >> Hello Chris, >> >> Yes, if the WG decides to put in something about gateways in the >> document, that will require more work. I don't know if you had >> a look at the expired document that I posted a few days ago on >> the subject of gateways, but the discussion on the list also in my >> opinion shows that the matter is not settled for OLSRv2 either. >> I'm sure you can sift through the emails and find various points >> that are not settled and still worthy of discussion. >> >> I strongly believe that the subject is important enough to merit >> a separate effort. And, while it is true that proactive is easier, >> there are many design issues in common, so that a separate >> document could be made to apply to both proactive and reactive. >> >> Perhaps after my local fires (IEEE, etc.) have died down in a few >> more days, I'll write up a requirements draft for Gateways that >> enumerates the issues raised here on the list as well as others >> discussed in the past. It's not as easy as just saying "0/0". >> >> >> >> On 12/12/2012 10:03 AM, Dearlove, Christopher (UK) wrote: >>> I think given that there was discussion just in the last week or two on >>> the status of gateways, that's just one example where features aren't >>> stable. And I don't believe the WG has actually expressed a view on much >>> of what's in or not in the document. >>> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From charliep@computer.org Tue Jan 15 08:34:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B83621F8623 for ; Tue, 15 Jan 2013 08:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4jAyoOB-ck6 for ; Tue, 15 Jan 2013 08:34:33 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 329F221F85D6 for ; Tue, 15 Jan 2013 08:34:27 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tv9T0-0001VN-MG; Tue, 15 Jan 2013 11:34:26 -0500 Message-ID: <50F5850E.3060809@computer.org> Date: Tue, 15 Jan 2013 08:34:22 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86dbe5a49aca702e72f87b2a162f944375350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:34:33 -0000 Hello Chris, I don't think it's hard at all to do the extension you suggest. On the other hand, in all the years I've been in manet, this is the first time anyone suggested it might be useful... Regards, Charlie P. On 1/15/2013 5:22 AM, Dearlove, Christopher (UK) wrote: > To my mind, a critical question is whether an RREQ or an RREP might, at some point, carry more than one address in what is the main address category. > > Could an RREQ carry more than one address "I'm looking for A and/or B"? (and/or, as I could see either being a possibility). > Could an RREP carry more than one address - either "you asked for A, I am A. I'm also B, C and D" or with IRREPs "I also route to B, C and D". > > This sort of information could be flagged with TLVs. Positionally it's much harder - especially if we may want to add such cases later. > -- Regards, Charlie P. From sratliff@cisco.com Tue Jan 15 08:52:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7221F8623 for ; Tue, 15 Jan 2013 08:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssUpusG-vLpT for ; Tue, 15 Jan 2013 08:52:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A55D821F85C2 for ; Tue, 15 Jan 2013 08:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1298; q=dns/txt; s=iport; t=1358268776; x=1359478376; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4QFOqia9w7XGxxMILjpuZmII29k3qLRphOAR/dXVmpQ=; b=DwekeX2eoln4e5Bi1O7Oihzh8UU9vyeXIhF0J5E7o19wpxpW8GFSE7QK QvIsFS1clduJNod7StCBQLqkEjYlG3x+RmONgwiDyg9bQJH+ZdK8nwNbv tXvOSfZwfFUY0GjYUDjmAq+ZFMxG1sksCzUbiWe62nM3fXMsROnFlNHcP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAOOI9VCtJXHB/2dsb2JhbABFuj2DSBZzgh4BAQEDAQEBAWsJAhACAQgYCiQnCyUCBA4FCIgLBgyob45CBJBXYQOmVYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="162657444" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jan 2013 16:52:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0FGqtvX029488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 16:52:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 10:52:54 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAAm38AgAAFLYA= Date: Tue, 15 Jan 2013 16:52:54 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFEE7E4@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> In-Reply-To: <50F5850E.3060809@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:52:59 -0000 On Jan 15, 2013, at 11:34 AM, Charles E. Perkins wrote: >=20 > Hello Chris, >=20 > I don't think it's hard at all to do the extension you suggest. >=20 > On the other hand, in all the years I've been in manet, this is the > first time anyone suggested it might be useful=85 I for one can see the utility, regardless of how long it took the idea to c= ome up.=20 Regards, Stan >=20 > Regards, > Charlie P. >=20 >=20 > On 1/15/2013 5:22 AM, Dearlove, Christopher (UK) wrote: >> To my mind, a critical question is whether an RREQ or an RREP might, at = some point, carry more than one address in what is the main address categor= y. >>=20 >> Could an RREQ carry more than one address "I'm looking for A and/or B"? = (and/or, as I could see either being a possibility). >> Could an RREP carry more than one address - either "you asked for A, I a= m A. I'm also B, C and D" or with IRREPs "I also route to B, C and D". >>=20 >> This sort of information could be flagged with TLVs. Positionally it's m= uch harder - especially if we may want to add such cases later. >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Jan 15 09:05:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5825721F863F for ; Tue, 15 Jan 2013 09:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewpZaqm5a-3E for ; Tue, 15 Jan 2013 09:05:38 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9421F8588 for ; Tue, 15 Jan 2013 09:05:38 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tv9xC-0004T7-2I; Tue, 15 Jan 2013 12:05:38 -0500 Message-ID: <50F58C5D.1000103@computer.org> Date: Tue, 15 Jan 2013 09:05:33 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad862bbd3fd4797d60142096fe0240dfc77e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:05:39 -0000 Hello Chris, small follow-up: On 1/15/2013 5:22 AM, Dearlove, Christopher (UK) wrote: > > Could an RREQ carry more than one address "I'm looking for A and/or B"? (and/or, as I could see either being a possibility). Presumably you would never want exclusive "or"...? > Could an RREP carry more than one address - either "you asked for A, I am A. I'm also B, C and D" or with IRREPs "I also route to B, C and D". That would not be iRREP. In AODVv2 it would be handled by the AdditionalNode AddrBlk. > > This sort of information could be flagged with TLVs. Positionally it's much harder - especially if we may want to add such cases later. There's no conflict between positional and TLV usage. The design of the TLV would depend on whether the address list had positional requirements. -- Regards, Charlie P. From ulrich@herberg.name Tue Jan 15 09:35:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD7121F8703 for ; Tue, 15 Jan 2013 09:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCJwrRCR1Klw for ; Tue, 15 Jan 2013 09:35:21 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id F410521F86AE for ; Tue, 15 Jan 2013 09:35:20 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so389575vbi.32 for ; Tue, 15 Jan 2013 09:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GNiHdZREwPWp3qjeyP0+5A2dn07IW3uVAHJg2B5dsfU=; b=BTg1Nj60/S6MwfW5o+ktVp+mlf9/EeR66TRnstI/lnbtIdyk9aXJKAqZzLxk0D8FkH Hqa8N75B499+sypbhiP/LH/GyTwHVVGVOULv35GQru2EiGQTPXi2gNwmflLdPXYCWXXR 0D9aPPcecDaGQCbYx51be/PeLz66GVCcw1CXI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=GNiHdZREwPWp3qjeyP0+5A2dn07IW3uVAHJg2B5dsfU=; b=bqJK9F0dOc/OCGVollUpdCRWNIz9lGO7LnBBwWpwc8eaKSY6LCWDFiZSWyLq5OMw87 Qvld1y3nEIPdOW4feDsSdqxhtmRWYiaRJhsnrR8y60V2WDX4IPNifPGU24IRf4LsEKcU vUfeLd3/Dx3K7bV767S8fUDshFHFd1vH466R9K4sWawhiXjZUJfwUr8B6V5iQaV5gASs O6idCHNrybwV9v4BZa46NNmgUKVSKxqOoe5aGw79Z+mv8Wx19fUK3o1l+I1mXvE0/kfm ZDyeGEsfEiKgbMnq1eTnVzzM0F8gj7bkIs/ZAU8Ob4ULf3peP+MaeWDztuCyZ7NbEh1R 86mw== MIME-Version: 1.0 Received: by 10.58.233.210 with SMTP id ty18mr95224957vec.46.1358271320068; Tue, 15 Jan 2013 09:35:20 -0800 (PST) Received: by 10.220.5.16 with HTTP; Tue, 15 Jan 2013 09:35:19 -0800 (PST) In-Reply-To: References: <50F53CC2.6040205@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 09:35:19 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=089e0102ee7c8a942c04d3572f1f X-Gm-Message-State: ALoCoQkXYTkxWHBpXuznnIR+shKhrhF3Or4t4ULlG9oXAfwHEQzDccNx+cUDgCGyoSiFApfaVf7J Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:35:24 -0000 --089e0102ee7c8a942c04d3572f1f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB, these are four different implementations, implemented by different people solely based on the LOADng draft. They have been successfully tested in these multiple interop tests. Best regards Ulrich On Tue, Jan 15, 2013 at 3:34 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Henning, > > thanks alot, but I think the tests reported by the doc is only for one > implementation, not all 4 LOADng implementations, however, I will > contact the authors of the doc, thanks, > > AB > > On 1/15/13, Henning Rogge wrote: > > On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: > >> As you agree with RFC2026, I can understand you mean that the 4 > >> implementation you refered to previously are interoperable, please > >> confirm, and that they may work together, > > > > Maybe this will answer your question? I think this document was already > > mentioned on this list. > > > > > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-04 > > > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0102ee7c8a942c04d3572f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

these are four different implementations, implemented by differe= nt people solely based on the LOADng draft. They have been successfully tes= ted in these multiple interop tests.

Best regards
Ulrich

On Tue, Jan 15, 2013 at 3:34 AM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Henning,

thanks alot, but I think the tests reported by the doc is only for one
implementation, not all 4 LOADng implementations, however, I will
contact the authors of the doc, thanks,

AB

On 1/15/13, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
> On 01/15/2013 12:14 PM, Abdussalam Baryun wrote:
>> As you agree with RFC2026, I can understand you mean that the 4 >> implementation you refered to previously are interoperable, please=
>> confirm, and that they may work together,
>
> Maybe this will answer your question? I think this document was alread= y
> mentioned on this list.
>
> http://tools.ietf.org/html/draft-lave= nu-lln-loadng-interoperability-report-04
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
> mailto:henning.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
>
_______________________= ________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--089e0102ee7c8a942c04d3572f1f-- From charliep@computer.org Tue Jan 15 09:46:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1104421F86E3 for ; Tue, 15 Jan 2013 09:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osRstqtsEeI9 for ; Tue, 15 Jan 2013 09:46:55 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 51EB621F86CA for ; Tue, 15 Jan 2013 09:46:55 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvAb8-0006CD-74; Tue, 15 Jan 2013 12:46:54 -0500 Message-ID: <50F5960A.1020701@computer.org> Date: Tue, 15 Jan 2013 09:46:50 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> In-Reply-To: <50F3B1A9.4050205@fkie.fraunhofer.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8674b03dfd494863dcea72ba4322eabfa1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:46:56 -0000 Hello Henning, Early last year, I sent out a long email detailing design choices for encoding the two required addresses for RREQ and RREP into an AddrBlk with various possibilities for TLVs. Because of the "usual case" compression with IPv6 addresses, I picked the design that is now in AODVv2, after waiting for comments from the mailing list. LOADng picked another of the design points that I had laid out. Since there is only one address in the LOADng AddrBlk, it's pretty easy for it to be position-independent. However, the LOADng design also eliminates the possibility for address compression which is the raison d'etre for RFC 5444. Please note that as far as I know LOADng had made their design decisions before my email. It wasn't discussed on the issue tracker. There are several other reasons for putting both addresses into the AddrBlk, which if you're interested I can recapture from the earlier email. Since there's no RREQ/RREP in OLSR, these issues (I guess) were never completely explored before. My understanding of RFC 5444 (pretty good at this point) and OLSR is that they were made for each other, and the reactive design requirements were not at the time as clear as they are now. Regards, Charlie P. > > > There are two advantages of this: > 1.) You can use a generic parser to parse AODVv2. Well, it can't be "too" generic! > 2.) The IMPLEMENTATION can decide on the order of addresses to allow > better compression of the binary RFC5444 message. What if no possible compression of position-independent specification can be better than the position-dependent version? Aren't all RFC5444 messages binary? > >> 3a. Why does it matter? > > Yes, I think it does. > >> The major work of the RREQ/RREP seems to have a short block of 2 >> ADDRTLVs. The longer optional addresses (a DSR sort-of source routing) >> seems come second and provide potential better paths. It would make >> processing sense to grab the first block to process to get a basic >> connection (before the nodes move on), and then fine tune). It could be >> considered “make before you tune it” (a variant of the make before >> break concept). >> >> BGP implementation often try to pack things in the packet so the most >> important processing comes first. > > Implementations could do this, but the protocol specification should > not demand it. The protocol specification should just say "add address > X with TLV Y to signal Z". This means more TLVs to supply the positional information, instead of just having the positional information inherently understood based on the message type. There's no free lunch. The state resides somewhere. I'd say our job is to make efficient yet natural encodings for the required information. > > Making the protocol depend on position and split of addresses is a > step backward from a TLV format towards a binary format where parts of > the information is hidden in the order of non-annotated fields. Hidden is a loaded term. The information is "hidden" in the message type, and in the protocol specification. More annotations ---> larger message sizes, and we're already dealing with various enlargements due to other RFC 5444 features. -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Tue Jan 15 10:04:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A12C21F86B3 for ; Tue, 15 Jan 2013 10:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vlNlJ3knr3b for ; Tue, 15 Jan 2013 10:04:05 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2021F8645 for ; Tue, 15 Jan 2013 10:04:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,475,1355097600"; d="scan'208";a="255284369" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 15 Jan 2013 18:04:04 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0FI44Wb007768 for ; Tue, 15 Jan 2013 18:04:04 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6956"; a="3421516" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 15 Jan 2013 18:04:04 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Tue, 15 Jan 2013 18:04:04 +0000 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Charles E. Perkins" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAANuoAgAAFLgCAABJDsA== Date: Tue, 15 Jan 2013 18:04:03 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFEE7E4@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFEE7E4@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:04:06 -0000 My point is that 5444 was designed for flexibility. (It tried a compromise = also with efficiency and simplicity, but that's another matter.) The "all = information needs a TLV" approach maintains, and even extends, that flexibi= lity. My point is not that those specific items are definitely good (though= I tried to pick at least plausible ones) but that you may not know now wha= t you want later. With regard to cost, allowing flexibility of ordering might save what havin= g a TLV cost you. though it might not. Not forcing more than one address bl= ock will save you more than it cost you in any but unusual circumstances. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] = Sent: 15 January 2013 16:53 To: Charles E. Perkins Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Jan 15, 2013, at 11:34 AM, Charles E. Perkins wrote: > = > Hello Chris, > = > I don't think it's hard at all to do the extension you suggest. > = > On the other hand, in all the years I've been in manet, this is the > first time anyone suggested it might be useful. I for one can see the utility, regardless of how long it took the idea to c= ome up. = Regards, Stan > = > Regards, > Charlie P. > = > = > On 1/15/2013 5:22 AM, Dearlove, Christopher (UK) wrote: >> To my mind, a critical question is whether an RREQ or an RREP might, at = some point, carry more than one address in what is the main address categor= y. >> = >> Could an RREQ carry more than one address "I'm looking for A and/or B"? = (and/or, as I could see either being a possibility). >> Could an RREP carry more than one address - either "you asked for A, I a= m A. I'm also B, C and D" or with IRREPs "I also route to B, C and D". >> = >> This sort of information could be flagged with TLVs. Positionally it's m= uch harder - especially if we may want to add such cases later. >> = > = > = > -- = > Regards, > Charlie P. > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From shares@ndzh.com Tue Jan 15 10:12:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44A21F8712 for ; Tue, 15 Jan 2013 10:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIy-FcggXfZV for ; Tue, 15 Jan 2013 10:12:26 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 745D421F86D5 for ; Tue, 15 Jan 2013 10:12:26 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Henning Rogge'" , References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <004e01cdf2bf$679d2680$36d77380$@ndzh.com> <50F4F7F8.9080200@fkie.fraunhofer.de> In-Reply-To: <50F4F7F8.9080200@fkie.fraunhofer.de> Date: Tue, 15 Jan 2013 13:12:23 -0500 Message-ID: <005201cdf34b$de1de3d0$9a59ab70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zAaMHyk4DFdPHnwGT6LC+AXZozrKYMymhYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:12:27 -0000 Henning: Thank you for the example code. I will download the code, the api, and = the NHDP code.=20 I really appreciate all the input. I will be a bit later today as the = Wifi in the hotel was overload this am.=20 Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Tuesday, January 15, 2013 1:32 AM To: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) On 01/15/2013 02:26 AM, Susan Hares wrote: > Henning: > > Thank you for continuing this conversation. I am enjoying learning=20 > from you. > > > >> What if the message with the "magic number change" gets lost? That is = >> a > common thing in wireless networks. > > The magic number (0/-1) is a protocol constant. It can't get lost. I mean it can get lost in transmission. Wireless networks are unreliable = and have packet loss. So the packet with "here is the magic number, I = restarted my sequence numbers" could never arrive on the receiving nodes. > This is great news. We've got experience with the algorithm. > Did they find this algorithm difficult to debug? Not the code, but=20 > finding bugs in the deployment? Finding bugs in a community owned mesh network can be hard and painful.=20 Some people will have quite a technical knowledge and will be very = helpful. Others may not. Still, if the internet doesn't work, people will start complain quickly. >>> At the moment we have (I think, but I have to check) a standard=20 >>> compliant > "greater than" check in the code and some unique duplicate check=20 > system based on a 32bit >>shifting register (for each originator). > > Could you post the code if you get a chance? All code developed at olsr.org is on the website. The duplicate code is here: http://olsr.org/git/?p=3Dolsrd.git;a=3Dblob;f=3Dsrc/duplicate_set.h;h=3De= 5a761cb980e 0ea6fa527aeaeac118e60ef4386c;hb=3Dmaster http://olsr.org/git/?p=3Dolsrd.git;a=3Dblob;f=3Dsrc/duplicate_set.c;h=3D3= 04d02c20b86 f4dbe9619c934cadd1f4d03bfdc7;hb=3Dmaster v I am also working on a complete rewrite of our codebase to implement OLSRv2 in the long run, you will find the code in two repositories on olsr.org too: The new API for our program. Think about it as "routing agent without = the routing protocol". I hope we will use it for other programs too. http://olsr.org/git/?p=3Doonf_api.git;a=3Dsummary The NHDP/OLSRv2 application, which is using the API mentioned (at the = moment only NHDP): http://olsr.org/git/?p=3Dolsrd2.git;a=3Dsummary Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From hrogge@googlemail.com Tue Jan 15 10:43:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E8D11E80C5 for ; Tue, 15 Jan 2013 10:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAPwrEekZ+BS for ; Tue, 15 Jan 2013 10:43:52 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7D11E809C for ; Tue, 15 Jan 2013 10:43:51 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so508298lab.1 for ; Tue, 15 Jan 2013 10:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=77nOPNjJpJyT9OMoWQ6v/c6/nf7j5Q7txev07eBCK1U=; b=KtHeHnfhi+28k9LkbuBn7+ZY9XTquNfIEHPD737yRpwsHAqG65YDdGSmSiOP347i3P U/tiYT0PtoL852Py8ORZL9EM0Jep/UKnN2Jo3NqqVCyRzbhdReG+lq+/aG0rgxvtWFzG 9568l32dNVHLo3dimKAPR2sCyC2BZpVSVN/vzYHGpxMRZukxrxcwhU+OKM2jG6fjXsay NeqrHVSf0odn3yAm+J2JkjNT4ei8DgudYrYgB+e9Cl3mIX5JTdS1XiOgf4OOTatTLJo7 gPXzF1v8gURFn8reVfZO6yELvLGzW03VZ5zH1HDPMZvCsy5PMVZQqNsPLgpT8QDIcdgF 5KAg== Received: by 10.112.46.199 with SMTP id x7mr36819189lbm.109.1358275430405; Tue, 15 Jan 2013 10:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 10:43:29 -0800 (PST) In-Reply-To: <005201cdf34b$de1de3d0$9a59ab70$@ndzh.com> References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <004e01cdf2bf$679d2680$36d77380$@ndzh.com> <50F4F7F8.9080200@fkie.fraunhofer.de> <005201cdf34b$de1de3d0$9a59ab70$@ndzh.com> From: Henning Rogge Date: Tue, 15 Jan 2013 19:43:29 +0100 Message-ID: To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:43:52 -0000 On Tue, Jan 15, 2013 at 7:12 PM, Susan Hares wrote: > Henning: > > Thank you for the example code. I will download the code, the api, and the > NHDP code. I would really love to get some feedback about the APIs design. Until the first "stable" version of the olsr.org OLSRv2 is out, I can still change things to make it easier to use and understand. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Tue Jan 15 10:45:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7679E11E80A6 for ; Tue, 15 Jan 2013 10:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g15aPxXWriSi for ; Tue, 15 Jan 2013 10:45:07 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECBE11E809C for ; Tue, 15 Jan 2013 10:45:06 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fn20so492771lab.26 for ; Tue, 15 Jan 2013 10:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hO2NMuGxbRibgfDaPN1Gg+0moc2rVJhe5rbEsJbzIjg=; b=GMDzvedt5DOOPS+OxaknwPdR2SLzqyPc4e3mmu3dZMv0fLufn7Wt79TaXNNroaYWBN FlHqpWpyQccq0nEWtBiML0f/uANuC/Mc5JtvtFDBbIiPdFJz1FX15U2jDX+B8hoHxH1W bxGLUpKivAGXsCYzEhiRWb73HDYkkitzjjtNFSbX/+n5yk874lcxOASV9lfIhWCJbLXn sDYip3h1LWvigIf0wEpGneWCjbUaM+vVHLvqsxQFyh41J3XyaDYbzdNkOrhaY1CC2yea pXUuog4j0AxKnNPBoHL9EuzyQCirIqW48w5SsTECY3dIWCfHFAVYLne9EMz47OiWj+RM d+vA== Received: by 10.152.109.176 with SMTP id ht16mr686034lab.2.1358275505130; Tue, 15 Jan 2013 10:45:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 10:44:45 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFEE7E4@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Tue, 15 Jan 2013 19:44:45 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:45:07 -0000 On Tue, Jan 15, 2013 at 7:04 PM, Dearlove, Christopher (UK) wrote: > My point is that 5444 was designed for flexibility. (It tried a compromis= e also with efficiency and simplicity, but that's another matter.) The "al= l information needs a TLV" approach maintains, and even extends, that flexi= bility. My point is not that those specific items are definitely good (thou= gh I tried to pick at least plausible ones) but that you may not know now w= hat you want later. > > With regard to cost, allowing flexibility of ordering might save what hav= ing a TLV cost you. though it might not. Not forcing more than one address = block will save you more than it cost you in any but unusual circumstances. I completely agree to this. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Jan 15 10:52:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDA911E80E5 for ; Tue, 15 Jan 2013 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE927mg3rAdb for ; Tue, 15 Jan 2013 10:52:35 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8197F11E80DC for ; Tue, 15 Jan 2013 10:52:22 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fl15so475662vcb.18 for ; Tue, 15 Jan 2013 10:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AgfMF5yoQzEOT5Z+tbgAccoPmALVCZ7qParwVU8m/lc=; b=i/0fMwmEyd+ENPWdym9Pq3JTmKY/QMnBKX8Rlw++nXP3mZLjbWPf0XZ+oOd/v7dIoI WsDa616DhVlXpRir7rUQwLgw+3IeJIq4eQaI0+KMLFtIP9k35cKHDtjx3X/V591u9XFj rsoIYje5xZcBODUVG1mOUDM/LkgA8TLBqZUemhIVZzGdrDf3w0oRzElp17oF3wSPvg6s V8KzXQgZo9Q/A0Fiy63CfFT9do4GALMV7RLaChnrs8JUUmBt8zqlCcITE0cpPcKFKXEn fA47FxiK5V0xvrXhk5MwqrjFWgW4Xl1QWlspzbgKQTycCVxO7Q6PWb9yv5RUOrtNBcWr fDcg== MIME-Version: 1.0 Received: by 10.220.218.197 with SMTP id hr5mr104340524vcb.8.1358275940830; Tue, 15 Jan 2013 10:52:20 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 10:52:20 -0800 (PST) In-Reply-To: <50F5960A.1020701@computer.org> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> Date: Tue, 15 Jan 2013 19:52:20 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:52:35 -0000 On 1/15/13, Charles E. Perkins wrote: > Since there's no RREQ/RREP in OLSR, these issues (I guess) > were never completely explored before. My understanding > of RFC 5444 (pretty good at this point) and OLSR is that they > were made for each other, and the reactive design requirements > were not at the time as clear as they are now. The good thing that OLSRv2 was made for the RFC5444 and verse versa, because usually proactive protocols have higher overload of manet messages, so we needed that RFC5444 had good features for the manet proactive, and now we do the reactive part, but if we designing the reactive messaging and we think that RFC5444 needs few updates I think the right time for it is while doing that design, just my thoughts, AB From abdussalambaryun@gmail.com Tue Jan 15 11:14:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989F721F85E2 for ; Tue, 15 Jan 2013 11:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XriEP2HZy68i for ; Tue, 15 Jan 2013 11:14:39 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 25BAD21F85D7 for ; Tue, 15 Jan 2013 11:14:38 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id gb23so504256vcb.28 for ; Tue, 15 Jan 2013 11:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rRFqPu/W6F3lI804CgKA3COb7tVExCZIt72L8EaeG44=; b=O/GiO8dJdpqur154n8yDAQTN3zxnVfnwR6EW1VRyFhvKyjGznK47yU1aszvJnjJbyR S7k75Rhhige0uvYf6Y0KP2YEx+bEG2UABCzRsYQphzu9nJLnQYB9um3VpUfJshEyMi7r lC/r4QZxIBUO2c1Umi2/v/99tVdxDYHvZXwLLZthZceHK6/kFafy+eerS5OeC3W0Unrd JdxYqvMoT1mNLLsRJ6BrfM+7UFE8joch43sg66aVAkr/Wlm0uOMrW0SzZ2i1Jygowr4V 6c/sBhYlaZT0kwzFTK5UnEmktYaxNOab+lSwF3cXxR9dFgorNoCyraRk6a8slZLbqI1K BdrA== MIME-Version: 1.0 Received: by 10.220.149.69 with SMTP id s5mr106786027vcv.23.1358277278269; Tue, 15 Jan 2013 11:14:38 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 11:14:38 -0800 (PST) In-Reply-To: <50F5850E.3060809@computer.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> Date: Tue, 15 Jan 2013 20:14:38 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:14:41 -0000 Hello Charlie, > > I don't think it's hard at all to do the extension you suggest. > I agree with chris, that it is hard to extend when we are having in our design function a general manet packet format and fix position reactive message format, because I don't have a good knowledge of future, nor the best ways of using manet message formats, but the thing is that; Could the RFC5444 general format now be suitable for reactive routing future if routing was extended? or/and Should the manet format itself need to be extended for reactive routings? > On the other hand, in all the years I've been in manet, this is the > first time anyone suggested it might be useful... > That is maybe because the protocols were not implemented widely. however, It is good that we now think in that direction for future protocols in IETF. AB From hrogge@googlemail.com Tue Jan 15 11:23:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE321F8610 for ; Tue, 15 Jan 2013 11:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV2BWpsQVdxp for ; Tue, 15 Jan 2013 11:23:22 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB49021F84F3 for ; Tue, 15 Jan 2013 11:23:19 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id ep20so540923lab.4 for ; Tue, 15 Jan 2013 11:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=poY1Gxd2NxlsCved3c81HOLIfjW8Mqjp4N/pTYVSfz0=; b=OrsUBlQESFPnc2Y4d2P3JB8TJsHDOEqLSAzf0xiPuO6aBpQkIZotIGxzrGhJM7/TA3 lO63hLo5jPUzT48BubqTsXshZ87UjjO9RtvApmJiD7EwdPdVBISZPn0eNhrCgWZbd3lh h8OE6s40BzA3oZCDLQfg2a/7+482IoO4jzfPfod0i0ZLizTuGk9aJb/sGBgkqRPdfF5W aPZrZhetjMXtfwdt1NlpDcsGpRMTEVjJ0MpGIqoNuLHGx0M+u9Okp6SvhFWEjTkNFxKa +t+DNatRCRfrBFLR/cYCTW0IegwPk5++WdLLTbVzZooi4jgjjbrOU1h+VJZlJLASEQqM pChQ== Received: by 10.112.46.199 with SMTP id x7mr36870851lbm.109.1358277798786; Tue, 15 Jan 2013 11:23:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 11:22:58 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> From: Henning Rogge Date: Tue, 15 Jan 2013 20:22:58 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:23:33 -0000 On Tue, Jan 15, 2013 at 8:14 PM, Abdussalam Baryun wrote: >> I don't think it's hard at all to do the extension you suggest. > > I agree with chris, that it is hard to extend when we are having in > our design function a general manet packet format and fix position > reactive message format, because I don't have a good knowledge of > future, nor the best ways of using manet message formats, but the > thing is that; > > Could the RFC5444 general format now be suitable for reactive routing > future if routing was extended? or/and Should the manet format itself > need to be extended for reactive routings? Saying "we do not need to make it easy to extend a protocol" sounds like a good way to make a protocol obsolete quickly. >> On the other hand, in all the years I've been in manet, this is the >> first time anyone suggested it might be useful... > > That is maybe because the protocols were not implemented widely. > however, It is good that we now think in that direction for future > protocols in IETF. I have quite a few extensions planned for OLSRv2, all of them easy to do because of the TLV format. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Tue Jan 15 11:30:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CF421F844E for ; Tue, 15 Jan 2013 11:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r-a-O7gDT14 for ; Tue, 15 Jan 2013 11:30:04 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF321F84B2 for ; Tue, 15 Jan 2013 11:30:03 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id go10so435655lbb.13 for ; Tue, 15 Jan 2013 11:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ykpO3FUdvROlAcAUWNogkrF+bmLxI2CvE1q8o2+xr70=; b=n3v3VnsaBctdqdm0AhfZu1FpkfwxWhqFL+X32j+w0wRQ2zauSW9P07QIngDUbghTqs 9nMdSJlMEkvMfRzaCKR9R1JRlDeRnYbb8tnfn0sqobUFaDyQnCBNlcv1CFogSxwNd23Q M80AsvRFtNmMFYI1tbOZVq4jqkEx0nfTK3FgV4vztDeGGMB9p2lcryCnKkvK/3J3Czue tR/p/x0DO5RosoKYkPO+Cty5fTRamlbo3AoPP1sfbEqdf6wjuocFPTdmfBn3fRpXEjIB z0+OQ0MRG0VFup13WsBFX0V2f9uQ2ZkPnocmOXZvDDbPpAS+/C78guxngDbyzAh2u3DY QHag== Received: by 10.112.11.68 with SMTP id o4mr37274302lbb.128.1358278198648; Tue, 15 Jan 2013 11:29:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 11:29:37 -0800 (PST) In-Reply-To: <50F5960A.1020701@computer.org> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> From: Henning Rogge Date: Tue, 15 Jan 2013 20:29:37 +0100 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:30:05 -0000 On Tue, Jan 15, 2013 at 6:46 PM, Charles E. Perkins wrote: > > Hello Henning, > > Early last year, I sent out a long email detailing design choices > for encoding the two required addresses for RREQ and RREP > into an AddrBlk with various possibilities for TLVs. Because of > the "usual case" compression with IPv6 addresses, I picked > the design that is now in AODVv2, after waiting for comments > from the mailing list. I did some tests with IPv4 addresses in OLSRv1 TC sampled from the Vienna Funkfeuer network and they were compressable too. So its not only an IPv6 thing. But I agree, with IPv6 you (most times) get more advantage from the compression. >> There are two advantages of this: >> 1.) You can use a generic parser to parse AODVv2. > > Well, it can't be "too" generic! Generic parsers/generators will easily work for NHDP, OLSRv2, SMF and LOADng... but AODVv2 will need some strange special cases and extensions. >> 2.) The IMPLEMENTATION can decide on the order of addresses to allow >> better compression of the binary RFC5444 message. > > What if no possible compression of position-independent specification > can be better than the position-dependent version? Even if you have only a single address in your only address block, the overhead for putting in a TLV on it would be two byte. A small cost for having a clean protocol design. >> Implementations could do this, but the protocol specification should not >> demand it. The protocol specification should just say "add address X with >> TLV Y to signal Z". > > This means more TLVs to supply the positional information, instead of > just having the positional information inherently understood based on > the message type. > > There's no free lunch. The state resides somewhere. I'd say our job is > to make efficient yet natural encodings for the required information. Yes, sometimes its "2 byte overhead" vs. "special hack". This "positional information" is just a step backward to the packet formats we had with AODV and OLSRv1. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Jan 15 11:37:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DE021F8441 for ; Tue, 15 Jan 2013 11:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UM2-xwENQDy for ; Tue, 15 Jan 2013 11:37:49 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0921F8472 for ; Tue, 15 Jan 2013 11:37:48 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id p1so534471vcq.10 for ; Tue, 15 Jan 2013 11:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6NpFq0HNQ89U3PxVPWOByTV5dcA+ZuMQ1Uqq8oFzabk=; b=HmN5rAHRbJGoDsOLGAFTsZgMOf7Q+FcSoURAmiemEEIa1giGhkecrlwWLQ/oIPh243 5Ade5+xbQZkPH8O76QHr9b3gVxYcvgGtExRMCJ4kXtkFlY6Pf8SjHaGXbr9S3C/Idpvu yWPL6CmWp6L1Y2en3F7niNJUi8uXI8WpzwmTzYGmjNTEv21IMbgOoxziMDEFjIxys9cQ uznsSlo1ubovKFwX94nRyPZcvK72kfHry5wDobDVsp2acoEPMZwndb9R874U1bPrL9vM +V8p7r24Qcwx59OzGDRWHtyS0JRxNesnu276d3VCW4su9O2iOevlcdv1QPUGlsQxg9rd WMtw== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr91885431vdc.125.1358278667728; Tue, 15 Jan 2013 11:37:47 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 11:37:47 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> Date: Tue, 15 Jan 2013 20:37:47 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:37:49 -0000 On 1/15/13, Henning Rogge wrote: > > Saying "we do not need to make it easy to extend a protocol" sounds > like a good way to make a protocol obsolete quickly. I didn't say that, but I like your respond (similar to what I agreed about Chris comment) because it was what I wanted to say. However, I ment to add also, we never should forget that any RFC the WG produces may make things easy or difficult depending on how we use them in other/future works. > I have quite a few extensions planned for OLSRv2, all of them easy to > do because of the TLV format. > extending the routing function maynot mean changing the routing information format, AB From abdussalambaryun@gmail.com Tue Jan 15 11:47:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7409421F8546 for ; Tue, 15 Jan 2013 11:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvHHdK7MPTJi for ; Tue, 15 Jan 2013 11:47:20 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 911A821F8542 for ; Tue, 15 Jan 2013 11:47:20 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id ez10so526621vbb.39 for ; Tue, 15 Jan 2013 11:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=06b5A5CMY8MwdFqhQjxfLyKaIIBzwlel7NdrxWCaSCI=; b=Rt4YVxsyaySPa0guwDgQf0RbfArCuoEaNwAMFsLR7OhHoirXdt4l4n/CE0UgMhTE0w FsA7O8tkTDkvk/Mf3p6rjA+q2WEYhRMzI4W3DOrK4NyiKvJi0yuTT0d4q5pTzyPbGsLH P5TyJIz7mCIoxiOFFHf6IUtSgrlDE5PNZQaA4KfLpsNuLhG+IZePSowdjpT7piy9Ig2M nfKNu1cQipbLFOahHnjuxKe30wyhcN8bgwIRSPy2z9Gfrt8eFt3IBGCTmTLsToUbP19B tN/052Fno21BA+bhbG1Cwrzaav62wJ0fej4J6JRvAJotdKyG6DMVrzREwl0HqYJRaKHA H1Ig== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr106940985vcq.31.1358279239712; Tue, 15 Jan 2013 11:47:19 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 11:47:19 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> Date: Tue, 15 Jan 2013 20:47:19 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:47:21 -0000 On 1/15/13, Henning Rogge wrote: >> There's no free lunch. The state resides somewhere. I'd say our job is >> to make efficient yet natural encodings for the required information. > > Yes, sometimes its "2 byte overhead" vs. "special hack". > > This "positional information" is just a step backward to the packet > formats we had with AODV and OLSRv1. I think that the some position information in AODVv2 is flexible and different than the old versions. Not sure what you mean backward, AB From hrogge@googlemail.com Tue Jan 15 11:59:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318D811E809A for ; Tue, 15 Jan 2013 11:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOjFgzKH+MuK for ; Tue, 15 Jan 2013 11:59:46 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id B031E11E8099 for ; Tue, 15 Jan 2013 11:59:38 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id l5so455304lbo.37 for ; Tue, 15 Jan 2013 11:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1oePKLDkE1sZDAMcao+gF3ZYRwzQtKVARsPlDruG3+Q=; b=BZNqhmmKon0sDAQghsW+yDBkD+kIp2LkCAyQvWeAHkx+bu9vCjfYB1ILivsp8JYMDN yYI/VG8s+jBddBGzSWTcY3dMN64o8im1DR68lwXs/siFf7dijBjaA9kAuGG1g3fRBr9r H1m170FgF2+K/yAQjw4fSUrIm42zQY9QxQHlomqhE2cgX6sv0BMpKzzkWCGV1hFUpDWT e8GGxCa/qmu0ymXdDfJSZ5i5ayjxn0Ifzs7xfM37JtZuN3/ytX3QqYn8RfCMDrItxT1x dxOekkQfMjC4QpaTfbbL5sRfVgVGu3kAUgZif1RdhsGUgh/644GSNmJg3ZoZFNwioAJA jZbw== Received: by 10.152.109.176 with SMTP id ht16mr916821lab.2.1358279974186; Tue, 15 Jan 2013 11:59:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 11:59:14 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> From: Henning Rogge Date: Tue, 15 Jan 2013 20:59:14 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:59:48 -0000 On Tue, Jan 15, 2013 at 8:47 PM, Abdussalam Baryun wrote: > On 1/15/13, Henning Rogge wrote: >>> There's no free lunch. The state resides somewhere. I'd say our job is >>> to make efficient yet natural encodings for the required information. >> >> Yes, sometimes its "2 byte overhead" vs. "special hack". >> >> This "positional information" is just a step backward to the packet >> formats we had with AODV and OLSRv1. > > I think that the some position information in AODVv2 is flexible and > different than the old versions. Not sure what you mean backward, Both AODV and OLSR encoded the meaning of the bytes without their messages in their position relative to the start of the message. I think RFC5444 was meant as a replacement to use TLVs for this. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From charliep@computer.org Tue Jan 15 12:03:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC221F84F5 for ; Tue, 15 Jan 2013 12:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AUfVcTIbM4P for ; Tue, 15 Jan 2013 12:02:32 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 683F311E80E1 for ; Tue, 15 Jan 2013 12:00:26 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvCft-0000IZ-Uj; Tue, 15 Jan 2013 14:59:58 -0500 Message-ID: <50F5B539.5000502@computer.org> Date: Tue, 15 Jan 2013 11:59:53 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866529030117924dabd704b503450042dc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:03:34 -0000 Hello Abdussalam, On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: > > I agree with chris, that it is hard to extend when we are having in > our design function a general manet packet format and fix position > reactive message format, because I don't have a good knowledge of > future, nor the best ways of using manet message formats, but the > thing is that; On the one hand, it's probably true that placing positional constraints on top of RFC 5444 constraints makes future designs harder (that is almost a tautology). Similarly, placing RFC 5444 constraints has itself made future designs more difficult. On other hand, there's a lot of protocols out there that have positional constraints (at all layers!) and we know how to do that. In particular, AODV (the experimental protocol) did not seem to encounter any difficulty with extensions, many of which never made it to the IETF, and I don't remember any complaint about the positional nature of AODV parameters in the message formats until this discussion. So, for all practical purposes, the argument that "positional == bad" simply does not match my experience. As in many situations, each design deserves its own consideration. If positional designs make the packets smaller, that deserves to be considered, especially for wireless. I remember some recent discussion that there are more processor cycles than battery lifetime, which would motivate saving bytes over the air. It is always a tradeoff. > > That is maybe because the protocols were not implemented widely. > however, It is good that we now think in that direction for future > protocols in IETF. If this is a serious feature that is needed before we go forward with next steps, I can try to compose some specification language for it. I don't think it's too hard to do. -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Jan 15 12:15:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDF821F84B9 for ; Tue, 15 Jan 2013 12:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgsuhAeF80sy for ; Tue, 15 Jan 2013 12:15:42 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C621F84BA for ; Tue, 15 Jan 2013 12:15:41 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so573666vbb.10 for ; Tue, 15 Jan 2013 12:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FX1GCIU5dgPpLEpzdZbcpYg3CMxm/xUfUMvNf3ZEJuc=; b=zOkbNIb7y1RxyaX9WE5/zoLxYQglgYiyd4VXPh/TdQGxmkRcN9UFhzymZD00YZMarL KsfBhX+Fv+Hti/e+dn6uLuDaX8QmfDheyElXH2KEYxPHZg8E2c8AvuHrivVtweX4JiKt mjZ/QQG4EtHzTuX60uxLRRu+qO99LU2Y2qW5BKTFxtQqMYVytefAu2oBAtT90YlE4Dli GxVKLEyQmHF95ojghcjIEBZRwGKDMKtodb3BwZjtD1nR9cBqzEXnRutaLckVmPd+t9UQ IABYBJ18z+w9vy3O1LeBn4hOs3vMF+/Rwv4/jZadBtNBPikh8ymptuF60JD++Mc2vr0K Csow== MIME-Version: 1.0 Received: by 10.220.149.69 with SMTP id s5mr107021306vcv.23.1358280940948; Tue, 15 Jan 2013 12:15:40 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 12:15:40 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> Date: Tue, 15 Jan 2013 21:15:40 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:15:44 -0000 > Both AODV and OLSR encoded the meaning of the bytes without their > messages in their position relative to the start of the message. > > I think RFC5444 was meant as a replacement to use TLVs for this. > I think RFC5444 was meant as a replacement to use manet routing TLVs for any specified by the protocol best. For the proactive I agree the best is that replacement. The question is what is the best for reactive routing, for example; what will be the best practice for reactive protocol when using RFC5444? I am thinking now in this direction (without mixing thoughts of reactive and proactive as you are doing). AB From hrogge@googlemail.com Tue Jan 15 12:18:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B342C21F8414 for ; Tue, 15 Jan 2013 12:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiaCOTuvorVY for ; Tue, 15 Jan 2013 12:18:04 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 535FE21F8525 for ; Tue, 15 Jan 2013 12:18:03 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id fs13so606238lab.37 for ; Tue, 15 Jan 2013 12:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vVuik7Naqe9WWOMLRzUt29xldkHtSeYKWUVS7waSrXI=; b=0V4gYQIU7mISdguwmKwgqA/LSGm1s+xwCXKqiFYUXR1ztMrT+/CgSNlgPRJSel45j9 SnHT/XBfeN6fk3wdqBDBhO6tgxtSmg85QV7E0mJLlVHwxygxOFjzHCXXLKzFXJ1bO+IX NCoPS/4hJwdLPfF+aiMJ+oY4GLwJhbGfA4yBpY4wTTheykghTI0NcsxvHoN/+BCjhv9J PUte8F5wj94l+Smj+nMGh6652uFz9+w7BJagCKPnvynMq2Frgp9gE2xl/DZ9GGMlFJyt p2FX8DT358v69jfef8tS7E3RQtUOMAN6qeto9kTTcdhA38Rx5ups0RqTZ7F+P820bHRr Zzug== Received: by 10.152.113.165 with SMTP id iz5mr32017190lab.50.1358281082273; Tue, 15 Jan 2013 12:18:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 12:17:42 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> From: Henning Rogge Date: Tue, 15 Jan 2013 21:17:42 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:18:06 -0000 On Tue, Jan 15, 2013 at 9:15 PM, Abdussalam Baryun wrote: >> Both AODV and OLSR encoded the meaning of the bytes without their >> messages in their position relative to the start of the message. >> >> I think RFC5444 was meant as a replacement to use TLVs for this. >> > > I think RFC5444 was meant as a replacement to use manet routing TLVs > for any specified by the protocol best. For the proactive I agree the > best is that replacement. The question is what is the best for > reactive routing, for example; what will be the best practice for > reactive protocol when using RFC5444? I am thinking now in this > direction (without mixing thoughts of reactive and proactive as you > are doing). I don't think reactive or proactive makes a difference here. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Jan 15 12:21:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D811E80F1 for ; Tue, 15 Jan 2013 12:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzlkVVP6DR4Y for ; Tue, 15 Jan 2013 12:21:28 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 93EDF21F8512 for ; Tue, 15 Jan 2013 12:21:20 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so564887vbb.16 for ; Tue, 15 Jan 2013 12:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vnaqb8k5gQpJ1Vsbe5qC5LtOdXn7xpXtPS2aL8M/WEc=; b=gONzxWNsWaig0QaKZZ1Qu4cI7p94yQ2I4mCUfPFtwnCaTpoVI+khLHQ0N6mfH+cowB wzJT7Xtko0xp+18MxN4+mxkbvYLMQVyKAqWqGvJmRxXEFtz4DiPMYH63ke0xmtjDP1mH uxjSt1AHfwrt04mYe68PG5xjtAtuehkIvChYvFYtI7dcbLeoDylz2fEs/g2E4L/e3llD ZTR3jzDxAWUZo7+EIJ1pywVW+j+Zl4OhL1bippR2rLaH2cRVGgJoOiUTmkBW8oYgHf6E MC1Ryk3W09HwRC48mR86XWBOnaDhsdi/oZAA3kBwTVXBtE2gfjW6HOdXeuZNIaYh7MCf hK8Q== MIME-Version: 1.0 Received: by 10.220.8.18 with SMTP id f18mr104770370vcf.14.1358281279143; Tue, 15 Jan 2013 12:21:19 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 12:21:18 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> Date: Tue, 15 Jan 2013 21:21:18 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:21:32 -0000 Reactive routing message traffic is different than Proactive routing message traffic, the MANET routing traffic model of each routing is different even if they serve the same users. The RFC5444 is all about packing that traffic, do you still think they are same? AB On 1/15/13, Henning Rogge wrote: > On Tue, Jan 15, 2013 at 9:15 PM, Abdussalam Baryun > wrote: >>> Both AODV and OLSR encoded the meaning of the bytes without their >>> messages in their position relative to the start of the message. >>> >>> I think RFC5444 was meant as a replacement to use TLVs for this. >>> >> >> I think RFC5444 was meant as a replacement to use manet routing TLVs >> for any specified by the protocol best. For the proactive I agree the >> best is that replacement. The question is what is the best for >> reactive routing, for example; what will be the best practice for >> reactive protocol when using RFC5444? I am thinking now in this >> direction (without mixing thoughts of reactive and proactive as you >> are doing). > > I don't think reactive or proactive makes a difference here. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From hrogge@googlemail.com Tue Jan 15 12:27:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247A1F0C5F for ; Tue, 15 Jan 2013 12:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRQSckF4lrgI for ; Tue, 15 Jan 2013 12:27:31 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id BB4E31F0C3E for ; Tue, 15 Jan 2013 12:27:30 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id gi11so476381lbb.33 for ; Tue, 15 Jan 2013 12:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8FbMQ7VyXOpZg/ie5SuhwrY1lH9F2Fo1D6dXFd42YJI=; b=vBI24Lm5Bl9bp7gXHIhHW6TVvMykFn8rmwfX0cMIAgRsHcc/y3LYDNP5b7t+QiHu/D p3WpetWBGD64/DsdaIbtIAbugSpjiESndrZapSXcSR3aW0VwOHxStNqYM09NL8GUnIGM 5qI7uxt5NxzcyL5YcS5ncQvtoRdl5/NLAUmAXVqzW3oFDfzzZ5b38U/Hs5eZ1665GclE 8eJxiRe6i9hfq34PrtfPc5O+QRY5fc+nz48C/i5uFccVC64eVleFrlwxKe27PaZcXPK3 uTmiCxcbHYIsfr0HaPlu7Rg24eKyVHORtnUmJ8Ctu9fqowVU4rdjucJHS4AG0FZN8UQm nnEQ== Received: by 10.112.43.99 with SMTP id v3mr18014085lbl.103.1358281649634; Tue, 15 Jan 2013 12:27:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 15 Jan 2013 12:27:09 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> From: Henning Rogge Date: Tue, 15 Jan 2013 21:27:09 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:27:32 -0000 On Tue, Jan 15, 2013 at 9:21 PM, Abdussalam Baryun wrote: > Reactive routing message traffic is different than Proactive routing > message traffic, the MANET routing traffic model of each routing is > different even if they serve the same users. I know. > The RFC5444 is all about packing that traffic, do you still think they are same? I think that the same TLV format can serve the needs of both without the need of "position encoded information". Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Jan 15 12:34:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE38121F854E for ; Tue, 15 Jan 2013 12:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ap7nrbLKzg4 for ; Tue, 15 Jan 2013 12:34:19 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 87AC01F0C5F for ; Tue, 15 Jan 2013 12:34:19 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fl15so589928vcb.32 for ; Tue, 15 Jan 2013 12:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5lVKekfjeNNACLtqX3/09hhQNHm9yYlYxXfAtRs2FAA=; b=oussj6jUYWNj55kjkTMU5DbRRAf22EneY8NSknDId9FlIPkqHHY/NzNu/4bWGD5GeN OleR+EnMZp0YtsOYJriRDp5WZ56ntZOcONhjo3GOnD4ucfoqR+FrqHYSIAkTyjIomJyg WZiYrAQjMG7RrVEOv+4IVdawb92++T0VOGIAuBoqTDcLFqrlBO96iaMXJaN5JnvTKglR bQStw+tcHLYE3Y1qMstJSv1veEZRxarobbV9lbZd09xnimDHE6rAQFTTqilvIpLyWuvC dUE43uWpQjSFOTzC9WKHZYbv+7HxkVK5RNVamSS20l6dm5IEg47T2Mpb8bqVHXzpEwyv h4AA== MIME-Version: 1.0 Received: by 10.220.218.197 with SMTP id hr5mr104724799vcb.8.1358282058778; Tue, 15 Jan 2013 12:34:18 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 12:34:18 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> Date: Tue, 15 Jan 2013 21:34:18 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:34:20 -0000 On 1/15/13, Henning Rogge wrote: >> The RFC5444 is all about packing that traffic, do you still think they are >> same? > > I think that the same TLV format can serve the needs of both without > the need of "position encoded information". > Ok, I need an answer from any WG participant, to the question which I never claim that I know so far, but want to know; How/what is the best way to format RREQ and RREP as TLV in our reactive protocol in faivor of all scenarios served (please note that Proactive serve better different scenarios than Reactive do and verse versa)? AB From ulrich@herberg.name Tue Jan 15 12:37:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419F821F8551 for ; Tue, 15 Jan 2013 12:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pnLIAt6Tgma for ; Tue, 15 Jan 2013 12:37:12 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id ED0E21F0CAF for ; Tue, 15 Jan 2013 12:37:00 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so152209vbb.23 for ; Tue, 15 Jan 2013 12:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pfq5FJFHVFRlze92In3SUMlVUp57DbdIcaLi/oYjEUE=; b=vqIM7gp6R9PSJJ/E/4kr8698uGD79KgjKBF64TwPM1GZjKBqwHF60m4wOxGCPiLwKk GEy9biRveQrhXxfTCfHgcIj5VSD3XGyKT7n9AK7yRzfCfiQsHpiXOVXNkW2R8bi51rj6 fbk1MUUNwbdBWZ3nGQ1nCNLWMReal8stkR5cY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pfq5FJFHVFRlze92In3SUMlVUp57DbdIcaLi/oYjEUE=; b=ADi4UcDesuLjM4VTsdEtfGSfsjhk7HIb750VsSdiYW6n8V9/yyDr3TAAGQ/KwRdfGI jjEytfc/yOnrH8pyNfHn4gctZgY+zvOF3RL0ZZNVG+jbx2X8GWIeNNoozAsifGsyi2Nm rSM5S2ZIJBZkcBHC2wVVS9/N1gB/6rmlSi6OoxsgBaDPSVIuB8swIXiZdh0SLTTKX9GZ 6SifWHp2tNffSkWhsP6AzzTbsk5GBkn7pswBmGD/lNKSTmUheJ1lD0zk5KMp+VhV9Tx8 onu8exBJV4WkEx5R/262wot0iTKm2MyPdM+8o0orHqJqHkiF+q73MgaTjt4cj0WVdqoi 4exA== MIME-Version: 1.0 Received: by 10.220.149.73 with SMTP id s9mr2704959vcv.51.1358282220003; Tue, 15 Jan 2013 12:37:00 -0800 (PST) Received: by 10.220.5.16 with HTTP; Tue, 15 Jan 2013 12:36:59 -0800 (PST) In-Reply-To: <50F5B539.5000502@computer.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> Date: Tue, 15 Jan 2013 12:36:59 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=f46d04388ea93a601d04d359b989 X-Gm-Message-State: ALoCoQk1ijHOJl9qktOeJiyee4Uq8YVPaDG/t7xFtBvbH5izZnOKdK6Z2Or4Wt/TeM03x42YTj95 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:37:19 -0000 --f46d04388ea93a601d04d359b989 Content-Type: text/plain; charset=ISO-8859-1 Hello Charlie, I agree with Chris and Henning on this matter. You mention extensions for AODV where no problems have been observed. I think part of the reasons is that they (presumably) did not have to interoperate with other implementations that did not support that extension (no multiple vendors / multiple implementations in the same network). Henning mentioned to me once that his OLSR.org (OLSRv1) implementation has some extensions by having a different message type (I am sure he has more details). Sure, that works fine, as long as there are no other routers in the network that do not use the extension, and that therefore cannot know about the new message type. The problem with fixed positions and lengths is that it's hard to extend, and to remain backwards compatible / interoperable, which is a very nice feature about OLSRv2. You can still interoperate routers that only speak the "base" OLSRv2 and others that have extensions and attach new addresses and TLVs in any order or position or address block they want. You can use a common RFC5444 parser and generator for all of them. The flexibility and extensibility of OLSRv2 was one of the main reasons for developing it (compared to OLSR"v1"), and one of the main reasons the MANET WG standardized RFC5444. I have from my implementation experience, both for LOADng and OLSRv2 for which I developed multiple extensions, always appreciated this design choice. It made it very easy to develop in a very modular style, and not care much about backward compatibility. I think it would be useful to have a BCP for RFC5444 on that matter. Best regards Ulrich On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins wrote: > > Hello Abdussalam, > > > On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: > >> >> I agree with chris, that it is hard to extend when we are having in >> our design function a general manet packet format and fix position >> reactive message format, because I don't have a good knowledge of >> future, nor the best ways of using manet message formats, but the >> thing is that; >> > > On the one hand, it's probably true that placing positional constraints > on top of RFC 5444 constraints makes future designs harder (that is > almost a tautology). Similarly, placing RFC 5444 constraints has itself > made future designs more difficult. > > On other hand, there's a lot of protocols out there that have positional > constraints (at all layers!) and we know how to do that. In particular, > AODV (the experimental protocol) did not seem to encounter any > difficulty with extensions, many of which never made it to the IETF, > and I don't remember any complaint about the positional nature of > AODV parameters in the message formats until this discussion. > > So, for all practical purposes, the argument that "positional == bad" > simply does not match my experience. As in many situations, each > design deserves its own consideration. If positional designs make the > packets smaller, that deserves to be considered, especially for wireless. > > I remember some recent discussion that there are more processor > cycles than battery lifetime, which would motivate saving bytes over > the air. It is always a tradeoff. > > > >> That is maybe because the protocols were not implemented widely. >> however, It is good that we now think in that direction for future >> protocols in IETF. >> > > If this is a serious feature that is needed before we go forward with > next steps, I can try to compose some specification language for it. > I don't think it's too hard to do. > > -- > Regards, > Charlie P. > > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --f46d04388ea93a601d04d359b989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Charlie,

I agree with Chris and Henning on this matter. You me= ntion extensions for AODV where no problems have been observed. I think par= t of the reasons is that they (presumably) did not have to interoperate wit= h other implementations that did not support that extension (no multiple ve= ndors / multiple implementations in the same network). Henning mentioned to= me once that his OLSR.org (OLSRv1) implementation has some extensions by h= aving a different message type (I am sure he has more details). Sure, that = works fine, as long as there are no other routers in the network that do no= t use the extension, and that therefore cannot know about the new message t= ype.
The problem with fixed positions and lengths is that it's hard to exten= d, and to remain backwards compatible / interoperable, which is a very nice= feature about OLSRv2. You can still interoperate routers that only speak t= he "base" OLSRv2 and others that have extensions and attach new a= ddresses and TLVs in any order or position or address block they want. You = can use a common RFC5444 parser and generator for all of them. The flexibil= ity and extensibility of OLSRv2 was one of the main reasons for developing = it (compared to OLSR"v1"), and one of the main reasons the MANET = WG standardized RFC5444.
I have from my implementation experience, both for LOADng and OLSRv2 for wh= ich I developed multiple extensions, always appreciated this design choice.= It made it very easy to develop in a very modular style, and not care much= about backward compatibility.

I think it would be useful to have a BCP for RFC5444 on that matter.
Best regards
Ulrich

On Tue, Jan 1= 5, 2013 at 11:59 AM, Charles E. Perkins <charliep@computer.org>= wrote:

Hello Abdussalam,


On 1/15/2013 11:14 AM, Abdussalam Baryun wrote:

I agree with chris, that it is hard to extend when we are having in
our design function a general manet packet format and fix position
reactive message format, because I don't have a good knowledge of
future, nor the best ways of using manet message formats, but the
thing is that;

On the one hand, it's probably true that placing positional constraints=
on top of RFC 5444 constraints makes future designs harder (that is
almost a tautology). =A0Similarly, placing RFC 5444 constraints has itself<= br> made future designs more difficult.

On other hand, there's a lot of protocols out there that have positiona= l
constraints (at all layers!) and we know how to do that. =A0In particular,<= br> AODV (the experimental protocol) did not seem to encounter any
difficulty with extensions, many of which never made it to the IETF,
and I don't remember any complaint about the positional nature of
AODV parameters in the message formats until this discussion.

So, for all practical purposes, the argument that "positional =3D=3D b= ad"
simply does not match my experience. =A0As in many situations, each
design deserves its own consideration. =A0If positional designs make the packets smaller, that deserves to be considered, especially for wireless.
I remember some recent discussion that there are more processor
cycles than battery lifetime, which would motivate saving bytes over
the air. =A0It is always a tradeoff.



That is maybe because the protocols were not implemented widely.
however, It is good that we now think in that direction for future
protocols in IETF.

If this is a serious feature that is needed before we go forward with
next steps, I can try to compose some specification language for it.
I don't think it's too hard to do.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d04388ea93a601d04d359b989-- From abdussalambaryun@gmail.com Tue Jan 15 12:41:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2ED1F0CB3 for ; Tue, 15 Jan 2013 12:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgVUM4rCTyOt for ; Tue, 15 Jan 2013 12:41:18 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id EDF9F1F0CAF for ; Tue, 15 Jan 2013 12:41:17 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id l6so595732vcl.9 for ; Tue, 15 Jan 2013 12:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bTPDtBzBl70o7CH+QGodN8P923lTCu1RuPHA8XvFYh8=; b=ZG/2WSlJNviZ3cfu0rdATwg7E9egjNyhe9giJTD+BbW6X5aaErawjDIaecDvTwtpEV srj5l1ULV0eA+zbh/tFWFIvvYKJ3sbCR10RNcf4eML3Z8wZ89Mf8wq4ONU0inw6kqyQm VWTi69d1mGm96neQk4b4omQeC5R8+lsX15QnWuQRAFNL5HAFvFXRNrQeNA3LVbA5yrQX BUwXBhSWan24AJvxCGO0BTpGXQ224c6SwrIBBlt/U9g9AM8OnWVd3zOM2x5KX3mpSVWb GBXOjT7XnK8axSvZ71MCkWoYOOkEVZa3k8v+NfnJxI154NUbqVDlPdLDHrrH1oiXUBHA AN1Q== MIME-Version: 1.0 Received: by 10.52.23.238 with SMTP id p14mr2110851vdf.86.1358282477330; Tue, 15 Jan 2013 12:41:17 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 12:41:17 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> Date: Tue, 15 Jan 2013 21:41:17 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:41:19 -0000 Hi Herberg, I think your design/approach of specifying the format for the LOADng and OLSRv2 will be great for hybrid routing scenarios, but is it the best design for most/all scenarios, AB On 1/15/13, Ulrich Herberg wrote: > Hello Charlie, > > I agree with Chris and Henning on this matter. You mention extensions for > AODV where no problems have been observed. I think part of the reasons is > that they (presumably) did not have to interoperate with other > implementations that did not support that extension (no multiple vendors / > multiple implementations in the same network). Henning mentioned to me once > that his OLSR.org (OLSRv1) implementation has some extensions by having a > different message type (I am sure he has more details). Sure, that works > fine, as long as there are no other routers in the network that do not use > the extension, and that therefore cannot know about the new message type. > The problem with fixed positions and lengths is that it's hard to extend, > and to remain backwards compatible / interoperable, which is a very nice > feature about OLSRv2. You can still interoperate routers that only speak > the "base" OLSRv2 and others that have extensions and attach new addresses > and TLVs in any order or position or address block they want. You can use a > common RFC5444 parser and generator for all of them. The flexibility and > extensibility of OLSRv2 was one of the main reasons for developing it > (compared to OLSR"v1"), and one of the main reasons the MANET WG > standardized RFC5444. > I have from my implementation experience, both for LOADng and OLSRv2 for > which I developed multiple extensions, always appreciated this design > choice. It made it very easy to develop in a very modular style, and not > care much about backward compatibility. > > I think it would be useful to have a BCP for RFC5444 on that matter. > > Best regards > Ulrich > > On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins > wrote: > >> >> Hello Abdussalam, >> >> >> On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: >> >>> >>> I agree with chris, that it is hard to extend when we are having in >>> our design function a general manet packet format and fix position >>> reactive message format, because I don't have a good knowledge of >>> future, nor the best ways of using manet message formats, but the >>> thing is that; >>> >> >> On the one hand, it's probably true that placing positional constraints >> on top of RFC 5444 constraints makes future designs harder (that is >> almost a tautology). Similarly, placing RFC 5444 constraints has itself >> made future designs more difficult. >> >> On other hand, there's a lot of protocols out there that have positional >> constraints (at all layers!) and we know how to do that. In particular, >> AODV (the experimental protocol) did not seem to encounter any >> difficulty with extensions, many of which never made it to the IETF, >> and I don't remember any complaint about the positional nature of >> AODV parameters in the message formats until this discussion. >> >> So, for all practical purposes, the argument that "positional == bad" >> simply does not match my experience. As in many situations, each >> design deserves its own consideration. If positional designs make the >> packets smaller, that deserves to be considered, especially for wireless. >> >> I remember some recent discussion that there are more processor >> cycles than battery lifetime, which would motivate saving bytes over >> the air. It is always a tradeoff. >> >> >> >>> That is maybe because the protocols were not implemented widely. >>> however, It is good that we now think in that direction for future >>> protocols in IETF. >>> >> >> If this is a serious feature that is needed before we go forward with >> next steps, I can try to compose some specification language for it. >> I don't think it's too hard to do. >> >> -- >> Regards, >> Charlie P. >> >> >> ______________________________**_________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/**listinfo/manet >> > From abdussalambaryun@gmail.com Tue Jan 15 15:10:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C532D1F0CF6 for ; Tue, 15 Jan 2013 15:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J2ykdieFzvr for ; Tue, 15 Jan 2013 15:10:33 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id AD5821F0CE4 for ; Tue, 15 Jan 2013 15:10:33 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id l6so727832vcl.9 for ; Tue, 15 Jan 2013 15:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Qj9AmgulZiTX+C1byGYlLTckjnbOJwuOwdwfNB9+yYA=; b=grQujU1pbc7ftKkOIdeXgX2Bl7v6f59RBrmO+ZI5DqOYUKsbDP2sZCpgeFkg714V1O wdj1iuDo2F7udwNdds6TmpTwoRCNGjTSVp2j981VlfyZh9P6qrscaKIqWyqJcDj+ybnP FsniW8KemjVaIColUr5xIz7gdB94q3D1k9PBhHP9sV56kO/vkZgIdaapO2146QqSz2Pd wGkof5Zbyo3OrwqaZ6MSV8sPPTZbMyVcM43A/+icb1OeZVsO3BHivH7FpuDwhOU+qieT ON6AmUSbLiqLPO/qx53isR80CKINWfH0vtv75tKMmdk6sF/FtT9A0j7MhWtElz/hvOUD FXeQ== MIME-Version: 1.0 Received: by 10.52.23.238 with SMTP id p14mr2536455vdf.86.1358291432841; Tue, 15 Jan 2013 15:10:32 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 15:10:32 -0800 (PST) Date: Wed, 16 Jan 2013 00:10:32 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Design Approaches toward the WG Reactive Protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:10:34 -0000 Hi All, I want to add to one input/mention my views on manet reactive routing that it is harder to design than proactive protocol within the Internet, that is why I think we need to careful when specifying its functions and messaging formats. As I think in history the first MANET routing was proactive and then reactive and then hybrid, which is similar what the standardizing steps we got through, all because harder is later. There is a problem that reactive work better in some application scenarios and proactive work better in other application scenarios, but both are important for MANETs in general. However, there are some application scenarios where the hybrid routing is the best choice for the MANET. Another problem is that generated routing information are different in reactive and proactive, so it will be reasonable that there may be different best formatting, which needs an answer/discuss. I disagree with the approach of RFC5444 to make the general design before the end of proactive and reactive separate standard. It was a good approach for hybrid routing of reactive and proactive design. However, I may be wrong but no one proved that similar formatting will give better performance for both protocols. It will be great if we make the WG reactive protocol work best without thinking of a hybrid or proactive routing, but just the reactive. I suggest to start from the documents of reactive we already discussed before, and go forward. Also I suggest we don't think about gateway issues as leave it in separate doc, it will only make things late to be submitted. Also, the BCP of general manet message format is separate (was that discussed very well, don't think so), we need now to know best practice of reactive routing format and then may discuss the general format (i.e. as more in faivor of hybrid approach). Abdussalam Baryun University of Glamorgan, UK +++++++++++++++ Sub:Re: [manet] Hares Technical Question 2: order of address in TLV On 1/15/13, Abdussalam Baryun wrote: > On 1/15/13, Henning Rogge wrote: >>> The RFC5444 is all about packing that traffic, do you still think they >>> are >>> same? >> >> I think that the same TLV format can serve the needs of both without >> the need of "position encoded information". >> > > Ok, I need an answer from any WG participant, to the question which I > never claim that I know so far, but want to know; How/what is the > best way to format RREQ and RREP as TLV in our reactive protocol in > faivor of all scenarios served (please note that Proactive serve > better different scenarios than Reactive do and verse versa)? > > AB > +++++++++++++ Sub: Re: [manet] Notifications from the IETF tools Issue Tracker On 1/15/13, Abdussalam Baryun wrote: > Hi Herberg, > > I think your design/approach of specifying the format for the LOADng > and OLSRv2 will be great for hybrid routing scenarios, but is it the > best design for most/all scenarios, > > AB > > On 1/15/13, Ulrich Herberg wrote: >> Hello Charlie, >> >> I agree with Chris and Henning on this matter. You mention extensions for >> AODV where no problems have been observed. I think part of the reasons is >> that they (presumably) did not have to interoperate with other >> implementations that did not support that extension (no multiple vendors >> / >> multiple implementations in the same network). Henning mentioned to me >> once >> that his OLSR.org (OLSRv1) implementation has some extensions by having a >> different message type (I am sure he has more details). Sure, that works >> fine, as long as there are no other routers in the network that do not >> use >> the extension, and that therefore cannot know about the new message type. >> The problem with fixed positions and lengths is that it's hard to extend, >> and to remain backwards compatible / interoperable, which is a very nice >> feature about OLSRv2. You can still interoperate routers that only speak >> the "base" OLSRv2 and others that have extensions and attach new >> addresses >> and TLVs in any order or position or address block they want. You can use >> a >> common RFC5444 parser and generator for all of them. The flexibility and >> extensibility of OLSRv2 was one of the main reasons for developing it >> (compared to OLSR"v1"), and one of the main reasons the MANET WG >> standardized RFC5444. >> I have from my implementation experience, both for LOADng and OLSRv2 for >> which I developed multiple extensions, always appreciated this design >> choice. It made it very easy to develop in a very modular style, and not >> care much about backward compatibility. >> >> I think it would be useful to have a BCP for RFC5444 on that matter. >> >> Best regards >> Ulrich From abdussalambaryun@gmail.com Tue Jan 15 15:30:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5814D1F0C6A for ; Tue, 15 Jan 2013 15:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scMQ1+YCxo4e for ; Tue, 15 Jan 2013 15:30:23 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id B47B61F0CE4 for ; Tue, 15 Jan 2013 15:30:23 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so739091vba.13 for ; Tue, 15 Jan 2013 15:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WmvldbMvamGQhmE9W5fRHwHyXCetbYVrenjetuY8jSg=; b=X7x9ChcGqhrZcJBeiZvMKeMUR9mGq/3NfniWJzUOS4ZKwn/yKp8F4mLFwOfpqx3WHU 1PlNLn0bRDSymEtq6kBF5Dfw/pphsqbi12/xc8LAu2lwlxHYIxAaAyjrRxwT5B86yWc0 /wlbfwbL5Psa+cCoxPl114llVkw2+e7yQBJWwdN/gKLn6GASHPBEFMSXq++3C3NvsxDH bMbDrzgSIjw7m0j7GRl0d6ofvg8CTfURJVk2K9X9HGPJbtyzej/DSxgqERhgrcE+KxTY SRYCGmb92IYxrjDngXVx/UFU8wyB/u0X7khwYaOWJRqZAHNvct2vzujXgWAlNNStTEd4 TQHw== MIME-Version: 1.0 Received: by 10.52.27.50 with SMTP id q18mr94585479vdg.20.1358292621899; Tue, 15 Jan 2013 15:30:21 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 15:30:21 -0800 (PST) In-Reply-To: <004e01cdf21c$87721860$96564920$@ndzh.com> References: <004e01cdf21c$87721860$96564920$@ndzh.com> Date: Wed, 16 Jan 2013 00:30:21 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Technical issue #6 - Non-optimal routes (warning - long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:30:24 -0000 Hi Sue, answers/comments in line, On 1/14/13, Susan Hares wrote: > Questions: > > 1. Where are the use cases for the MANET protocols that provide these > tradeoffs for congestion, node mobility, link loss and flooding? I asked that before, but the group don't like to put that in each document, it is done in MANET WG that we refer to RFC2501 which has all the use cases, > > 2. How is MANET judging the tradeoffs? > I think by testing or simulating codes, this is what I do, > 3. Stretch is a description of non-optimality. For example the stretch > value of 120 means the path is 20% longer. What is the normal stretch in > MANET? How does this compare with BGP=92s stretch? I never measured that or seen work done for that. Could you please give me a best reference so I get beter understanding, > > Thank you for any comments. Again, if I have missed papers or a discussio= n I try to do my best, > =96 > just let me know and I will find and read. > Me too I would like similar intentions. Regarding engineering referencing papers or discussions referencing is not done much in the IETF, which I hope to fix, All the best, AB From charliep@computer.org Tue Jan 15 15:55:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01F21F8561 for ; Tue, 15 Jan 2013 15:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIB96M-WOqNS for ; Tue, 15 Jan 2013 15:55:40 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEFE21F8558 for ; Tue, 15 Jan 2013 15:55:40 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvGLz-0004AK-7p; Tue, 15 Jan 2013 18:55:39 -0500 Message-ID: <50F5EC76.5020503@computer.org> Date: Tue, 15 Jan 2013 15:55:34 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e9551bd754fa2fae96cf3b4c0980e867350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:55:41 -0000 Hello Henning, It's clear that you prefer more TLVs instead of more contextual information. You express that explicitly, and also implicitly by some of chosen terminology. But there's often two sides to the story. Follow-up below... On 1/15/2013 11:29 AM, Henning Rogge wrote: > > > I did some tests with IPv4 addresses in OLSRv1 TC sampled from the > Vienna Funkfeuer network and they were compressable too. So its not > only an IPv6 thing. > > But I agree, with IPv6 you (most times) get more advantage from the compression. I didn't mean to exclude IPv4, but we agree the case for IPv6 is stronger. >>> There are two advantages of this: >>> 1.) You can use a generic parser to parse AODVv2. >> Well, it can't be "too" generic! > Generic parsers/generators will easily work for NHDP, OLSRv2, SMF and > LOADng... but AODVv2 will need some strange special cases and > extensions. Do you mean that the AddrBlk in AODVv2 is strange? Which extensions did you mean? The term "special cases", I could (try to) understand to mean cases not encountered by protocols retrieving sets of somehow "equivalent" addresses. Notably, "generic" is not the same as "our code". >>> 2.) The IMPLEMENTATION can decide on the order of addresses to allow >>> better compression of the binary RFC5444 message. >> What if no possible compression of position-independent specification >> can be better than the position-dependent version? > Even if you have only a single address in your only address block, the > overhead for putting in a TLV on it would be two byte. A small cost > for having a clean protocol design. But what if a "clean protocol design" is measured by requiring fewer "special case" TLVs? > > There's no free lunch. The state resides somewhere. I'd say our job is > > to make efficient yet natural encodings for the required information. > Yes, sometimes its "2 byte overhead" vs. "special hack". I really don't think that using the same design philosophy as has been used in hundreds of successful protocols should be called a "hack", and it certainly isn't "special" in that context. What about people who think RFC 5444 is a "hack", because there are ever more cases that require two-byte overhead here, two-byte overhead there, defining a new "hack" TLV when simple positional description would do? If they disappear from [manet] because their design ideas are labeled as "hacks", did RFC 5444 "win"? Moreover, as I understand it, it's not even just about RFC 5444, but about on the one hand conforming to someone's existing parser, and denigrating the word "positional". > This "positional information" is just a step backward to the packet > formats we had with AODV and OLSRv1. I'm not so sure which direction is forward. Anyway I hope it is clear that the overhead in the typical IPv6 RREQ/RREP case is much more than "2 bytes". -- Regards, Charlie P. From charliep@computer.org Tue Jan 15 15:59:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2EE21F860A for ; Tue, 15 Jan 2013 15:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-flWpJd8YQ9 for ; Tue, 15 Jan 2013 15:59:08 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2F21F85BC for ; Tue, 15 Jan 2013 15:59:07 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvGPK-0002WK-Sa; Tue, 15 Jan 2013 18:59:07 -0500 Message-ID: <50F5ED45.4010601@computer.org> Date: Tue, 15 Jan 2013 15:59:01 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad860ba7a04216ac831461c387e0a4063ad7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: manet Subject: Re: [manet] Design Approaches toward the WG Reactive Protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:59:08 -0000 Hello Abussalam, Small follow-up below... On 1/15/2013 3:10 PM, Abdussalam Baryun wrote: > As I think in history the first MANET > routing was proactive and then reactive and then hybrid, which is > similar what the standardizing steps we got through, all because > harder is later. One could argue that reactive came before proactive, but it isn't too germane to the discussion. Proactive presents its own set of "hard problems", many of which have been solved. The IETF history was that [manet] was started because of difficulties noted when applying the then-existing proactive protocols to ad hoc networks. -- Regards, Charlie P. From charliep@computer.org Tue Jan 15 16:39:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D027D21F85B8 for ; Tue, 15 Jan 2013 16:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbAzX7w9+WJx for ; Tue, 15 Jan 2013 16:39:40 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8713F21F85BB for ; Tue, 15 Jan 2013 16:39:40 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvH2Z-0005ta-Ae; Tue, 15 Jan 2013 19:39:39 -0500 Message-ID: <50F5F6C6.1000709@computer.org> Date: Tue, 15 Jan 2013 16:39:34 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ulrich Herberg References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060109040808000200040902" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ad4c4439d465bab20b602f1270710e05350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:39:41 -0000 This is a multi-part message in MIME format. --------------060109040808000200040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Ulrich, Continuing the discussion... On 1/15/2013 12:36 PM, Ulrich Herberg wrote: > Hello Charlie, > > ..... You mention extensions for AODV where no problems have > been observed. I think part of the reasons is that they (presumably) > did not have to interoperate with other implementations that did not > support that extension (no multiple vendors / multiple implementations > in the same network). In very few words, this presumption is not correct. To expand further: There are many protocols that have to deal with unknown extensions. Dealing with positional information is irrelevant if the type of the AddrTLVs or even more so the message type is unknown. Unless I am missing something, the positional information in the RteMsg AddrBlk is just not relevant to extensibility. Even in a further extension, it would not be relevant as long as (a) the semantics for skipping unknown extensions is clear and (b) it's possible to know the length of the unknown extension. No amount of TLVs will help implementations to deal with such matters if the above points are not obeyed. > > The problem with fixed positions and lengths is that it's hard to > extend, and to remain backwards compatible / interoperable, which is a > very nice feature about OLSRv2. Can you illustrate this claim given the existing AODVv2 AddrBlk and TLV structure? > > I have from my implementation experience, both for LOADng and OLSRv2 > for which I developed multiple extensions, always appreciated this > design choice. It made it very easy to develop in a very modular > style, and not care much about backward compatibility. I understand this to mean that you could use the same parser. Am I missing something? > > I think it would be useful to have a BCP for RFC5444 on that matter. Or maybe it's time for rfc5444bis -- but I don't want to tackle that problem until the light at the end of the current tunnel gets closer. Regards, Charlie P. > > On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins > > wrote: > > > Hello Abdussalam, > > > On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: > > > I agree with chris, that it is hard to extend when we are > having in > our design function a general manet packet format and fix position > reactive message format, because I don't have a good knowledge of > future, nor the best ways of using manet message formats, but the > thing is that; > > > On the one hand, it's probably true that placing positional > constraints > on top of RFC 5444 constraints makes future designs harder (that is > almost a tautology). Similarly, placing RFC 5444 constraints has > itself > made future designs more difficult. > > On other hand, there's a lot of protocols out there that have > positional > constraints (at all layers!) and we know how to do that. In > particular, > AODV (the experimental protocol) did not seem to encounter any > difficulty with extensions, many of which never made it to the IETF, > and I don't remember any complaint about the positional nature of > AODV parameters in the message formats until this discussion. > > So, for all practical purposes, the argument that "positional == bad" > simply does not match my experience. As in many situations, each > design deserves its own consideration. If positional designs make the > packets smaller, that deserves to be considered, especially for > wireless. > > I remember some recent discussion that there are more processor > cycles than battery lifetime, which would motivate saving bytes over > the air. It is always a tradeoff. > > > > That is maybe because the protocols were not implemented widely. > however, It is good that we now think in that direction for future > protocols in IETF. > > > If this is a serious feature that is needed before we go forward with > next steps, I can try to compose some specification language for it. > I don't think it's too hard to do. > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Regards, Charlie P. --------------060109040808000200040902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Ulrich,

Continuing the discussion...

On 1/15/2013 12:36 PM, Ulrich Herberg wrote:
Hello Charlie,

     .....   You mention extensions for AODV where no problems have been observed. I think part of the reasons is that they (presumably) did not have to interoperate with other implementations that did not support that extension (no multiple vendors / multiple implementations in the same network).

In very few words, this presumption is not correct.  To expand further:

There are many protocols that have to deal with unknown extensions.
Dealing with positional information is irrelevant if the type of the AddrTLVs
or even more so the message type is unknown.  Unless I am missing
something, the positional information in the RteMsg AddrBlk is just
not relevant to extensibility.  Even in a further extension, it would not
be relevant as long as (a) the semantics for skipping unknown extensions
is clear and (b) it's possible to know the length of the unknown extension.
No amount of TLVs will help implementations to deal with such matters
if the above points are not obeyed.


The problem with fixed positions and lengths is that it's hard to extend, and to remain backwards compatible / interoperable, which is a very nice feature about OLSRv2.

Can you illustrate this claim given the existing AODVv2 AddrBlk and TLV structure?


I have from my implementation experience, both for LOADng and OLSRv2 for which I developed multiple extensions, always appreciated this design choice. It made it very easy to develop in a very modular style, and not care much about backward compatibility.

I understand this to mean that you could use the same parser.
Am I missing something?


I think it would be useful to have a BCP for RFC5444 on that matter.

Or maybe it's time for rfc5444bis -- but I don't want to tackle that
problem until the light at the end of the current tunnel gets closer.

Regards,
Charlie P.


On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins <charliep@computer.org> wrote:

Hello Abdussalam,


On 1/15/2013 11:14 AM, Abdussalam Baryun wrote:

I agree with chris, that it is hard to extend when we are having in
our design function a general manet packet format and fix position
reactive message format, because I don't have a good knowledge of
future, nor the best ways of using manet message formats, but the
thing is that;

On the one hand, it's probably true that placing positional constraints
on top of RFC 5444 constraints makes future designs harder (that is
almost a tautology).  Similarly, placing RFC 5444 constraints has itself
made future designs more difficult.

On other hand, there's a lot of protocols out there that have positional
constraints (at all layers!) and we know how to do that.  In particular,
AODV (the experimental protocol) did not seem to encounter any
difficulty with extensions, many of which never made it to the IETF,
and I don't remember any complaint about the positional nature of
AODV parameters in the message formats until this discussion.

So, for all practical purposes, the argument that "positional == bad"
simply does not match my experience.  As in many situations, each
design deserves its own consideration.  If positional designs make the
packets smaller, that deserves to be considered, especially for wireless.

I remember some recent discussion that there are more processor
cycles than battery lifetime, which would motivate saving bytes over
the air.  It is always a tradeoff.



That is maybe because the protocols were not implemented widely.
however, It is good that we now think in that direction for future
protocols in IETF.

If this is a serious feature that is needed before we go forward with
next steps, I can try to compose some specification language for it.
I don't think it's too hard to do.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------060109040808000200040902-- From abdussalambaryun@gmail.com Tue Jan 15 19:01:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8243321F8512 for ; Tue, 15 Jan 2013 19:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xru4LR37p3zK for ; Tue, 15 Jan 2013 19:01:08 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id E705121F8528 for ; Tue, 15 Jan 2013 19:01:07 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id p16so880859vcq.11 for ; Tue, 15 Jan 2013 19:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9kRwuoInjyOdPYKCPsZ8q6OwpCivQJ9gsc+ENgLJ814=; b=D+M+gEwNI09sPk3aFcluZx1yGJR8Ze/yQcf+S4wtvHBmPm8VYxzWcuKCBXyuUaWDOP 5Ulmk66I5ghMEa3mbPjyKqv2CdnmBe3s3JLkLaYKR0cx+xbMG6y9JCvqNjUbSJfu3Twk Q6XUh6FedjRhfuIQQ/XsaDE/F+48Xsa5ARq0c0U1LgB2iS/F3Tga+lSDd7ufKjVGNg9g UbGs90zgE1KeqvgwrmNOH3+l062iE3M42dj/8UEV8EMatuosHkZGBNHgIZgjuovxfoxC ydB4iPvIGKacRZ8reJ5mHNPyZv6C2SZHsYI7fVcdAm4Nb7Iw1RAxVoQ8+JvNMCl5Ejk0 Sg8Q== MIME-Version: 1.0 Received: by 10.220.218.197 with SMTP id hr5mr105775025vcb.8.1358305267191; Tue, 15 Jan 2013 19:01:07 -0800 (PST) Received: by 10.220.145.5 with HTTP; Tue, 15 Jan 2013 19:01:07 -0800 (PST) In-Reply-To: <50F5F6C6.1000709@computer.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F5F6C6.1000709@computer.org> Date: Wed, 16 Jan 2013 04:01:07 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:01:08 -0000 > In very few words, this presumption is not correct. To expand further: > > There are many protocols that have to deal with unknown extensions. > Dealing with positional information is irrelevant if the type of the > AddrTLVs > or even more so the message type is unknown. Unless I am missing > something, the positional information in the RteMsg AddrBlk is just > not relevant to extensibility. Even in a further extension, it would not > be relevant as long as (a) the semantics for skipping unknown extensions > is clear and (b) it's possible to know the length of the unknown extension. > No amount of TLVs will help implementations to deal with such matters > if the above points are not obeyed. So far I see that the above is convencing me. However, I understand that you confirm that extending the AODVv2 with interoperable can be done without changing or using the way Chris and Henning explained. Best Regards AB +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In the future some participants will say have you discussed this issue, we may even forget, or forget where was it written, with unrelated reference subject title no one can search or find such stored info. Is this thread discussing tools/tracker? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From henning.rogge@fkie.fraunhofer.de Wed Jan 16 00:14:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8F21F8869 for ; Wed, 16 Jan 2013 00:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfOoPK2jVAOd for ; Wed, 16 Jan 2013 00:14:14 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBF021F8870 for ; Wed, 16 Jan 2013 00:14:12 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TvO8R-00019W-0L for manet@ietf.org; Wed, 16 Jan 2013 09:14:11 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TvO8Q-00082n-Tw for manet@ietf.org; Wed, 16 Jan 2013 09:14:10 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 16 Jan 2013 09:14:10 +0100 Message-ID: <50F6614B.5060909@fkie.fraunhofer.de> Date: Wed, 16 Jan 2013 09:14:03 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> In-Reply-To: <50F5EC76.5020503@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010202060207020106020901" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16502/Wed Jan 16 03:55:16 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b331db637f5f59503b2fb0e78bbbd54b Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 08:14:15 -0000 --------------ms010202060207020106020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/16/2013 12:55 AM, Charles E. Perkins wrote: > > Hello Henning, > > It's clear that you prefer more TLVs instead of more contextual > information. You express that explicitly, and also implicitly by > some of chosen terminology. But there's often two sides to > the story. Follow-up below... > > On 1/15/2013 11:29 AM, Henning Rogge wrote: >> >> >> I did some tests with IPv4 addresses in OLSRv1 TC sampled from the >> Vienna Funkfeuer network and they were compressable too. So its not >> only an IPv6 thing. >> >> But I agree, with IPv6 you (most times) get more advantage from the >> compression. > > I didn't mean to exclude IPv4, but we agree the case for IPv6 is strong= er. > >>>> There are two advantages of this: >>>> 1.) You can use a generic parser to parse AODVv2. >>> Well, it can't be "too" generic! >> Generic parsers/generators will easily work for NHDP, OLSRv2, SMF and >> LOADng... but AODVv2 will need some strange special cases and >> extensions. > > Do you mean that the AddrBlk in AODVv2 is strange? Which extensions di= d > you mean? The term "special cases", I could (try to) understand to me= an > cases not encountered by protocols retrieving sets of somehow "equivale= nt" > addresses. Notably, "generic" is not the same as "our code". just compare RFC5444 to a piece of XML. your way to encode the information is 10.0.0.1 10.0.0.2 with the hidden request that the first addr has a different meaning than = the second one. my idea about encoding would be something like this: 10.0.0.1 10.0.0.2 > But what if a "clean protocol design" is measured by requiring > fewer "special case" TLVs? If this is the case, why did we ever moved to a TLV format? Binary=20 format with most things defined by their order (and not a type) are=20 clearly "less overhead". But they can be a pain to extend later. > I really don't think that using the same design philosophy as has been > used in hundreds of successful protocols should be called a "hack", > and it certainly isn't "special" in that context. How many of them are TLV based formats? > What about people > who think RFC 5444 is a "hack", because there are ever more cases > that require two-byte overhead here, two-byte overhead there, > defining a new "hack" TLV when simple positional description would > do? If they disappear from [manet] because their design ideas are > labeled as "hacks", did RFC 5444 "win"? I am not aware of protocols leaving [manet] after RFC5444 got finalized. > Moreover, as I understand it, it's not even just about RFC 5444, > but about on the one hand conforming to someone's existing > parser, and denigrating the word "positional". > >> This "positional information" is just a step backward to the packet >> formats we had with AODV and OLSRv1. > > I'm not so sure which direction is forward. Anyway I hope it is > clear that the overhead in the typical IPv6 RREQ/RREP case is > much more than "2 bytes". After looking into the RREP specification in the current draft of=20 AODVv2, it might be even less than 2 bytes to skip the "position=20 information"... it could be zero bytes. The following is just an example for the RREP what we could do to get=20 rid of it. The RREP contains two addresses, both already "tagged" with an address=20 block TLV. We could easily take two message specific Address Block TLVs, one called = "Route Generation Sequence number" and one called "Route Request=20 Sequence Number" (the first one is similar to the Answer Set Number of=20 OLSRv2). This would allow AODVv2 to differentiate between your originator and=20 target address by looking at the TLV. (it might also allow nodes with multiple local addresses to reply to a=20 route request with more than one address, just by tagging multiple=20 addresses with the corresponding TLV) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010202060207020106020901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTYwODE0MDhaMCMGCSqGSIb3DQEJBDEWBBQoPa//Mq6Mb3iLQu7fK2Zh6rR+ITBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAdSRv0quD3oaaJIGdAGZvvbMGZx89MpWwFn/mPQ+hPCN3 OJRaABIlLup6ucyBzmXhw9EZ1sUA84+Rax1TsdKo9pLohmzM0WvJjNWMRDxknIzbfh4cJHMU mkVbYggyyCh+P5zW74ZP/q6hr3XOgDhVRxe2kW/pM+OotgvukDEafyRONC+jXZ8SVHof0swB As+0h1tzXNqKVjxeJi4XyT/TBVhV2KNc2QyVRJ4mmxVwp1ldsW3CMVgVAYd9Lz1N91RvOV+I n8BouPM5qCoxykq3rRPtyhPJQuYBrDEQp8EUFTzX4Ti0VTVGLqeXT3TeoH0T6NIL53VoCHqb RFf8sMO4OwAAAAAAAA== --------------ms010202060207020106020901-- From thomas@thomasclausen.org Wed Jan 16 00:40:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B280B21F8682 for ; Wed, 16 Jan 2013 00:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ7A76VLZZTY for ; Wed, 16 Jan 2013 00:40:21 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EC78921F8688 for ; Wed, 16 Jan 2013 00:40:20 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id B0342A64F5 for ; Wed, 16 Jan 2013 00:40:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0AAA01C0519; Wed, 16 Jan 2013 00:40:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.115] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0AA981C04E0; Wed, 16 Jan 2013 00:40:17 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: Date: Wed, 16 Jan 2013 09:40:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C8DD6B0-C4DF-4F06-ABE5-9B1C89F57F3F@thomasclausen.org> References: <50F53CC2.6040205@fkie.fraunhofer.de> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 08:40:21 -0000 No, it is for 4 different, independent implementations. As the I-D that = Henning cites clearly states. Thomas On Jan 15, 2013, at 12:34 , Abdussalam Baryun = wrote: > Hi Henning, >=20 > thanks alot, but I think the tests reported by the doc is only for one > implementation, not all 4 LOADng implementations, however, I will > contact the authors of the doc, thanks, >=20 > AB >=20 > On 1/15/13, Henning Rogge wrote: >> On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: >>> As you agree with RFC2026, I can understand you mean that the 4 >>> implementation you refered to previously are interoperable, please >>> confirm, and that they may work together, >>=20 >> Maybe this will answer your question? I think this document was = already >> mentioned on this list. >>=20 >> = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= -04 >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Wed Jan 16 01:46:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8CE21F841B for ; Wed, 16 Jan 2013 01:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4zeRcjYQ2NI for ; Wed, 16 Jan 2013 01:46:08 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 77EE521F81FF for ; Wed, 16 Jan 2013 01:46:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,478,1355097600"; d="scan'208";a="255395055" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Jan 2013 09:46:07 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0G9k7g4006245 for ; Wed, 16 Jan 2013 09:46:07 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6956"; a="3462890" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 16 Jan 2013 09:46:06 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Wed, 16 Jan 2013 09:46:07 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Abdussalam Baryun Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAANuoAgAAsxwCAAAylgIAA5oQQ Date: Wed, 16 Jan 2013 09:46:06 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> In-Reply-To: <50F5B539.5000502@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 09:46:10 -0000 Charlie > Similarly, placing RFC 5444 constraints has itself made future designs mo= re difficult. In what ways? -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 15 January 2013 20:00 To: Abdussalam Baryun Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Abdussalam, On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: > > I agree with chris, that it is hard to extend when we are having in > our design function a general manet packet format and fix position > reactive message format, because I don't have a good knowledge of > future, nor the best ways of using manet message formats, but the > thing is that; On the one hand, it's probably true that placing positional constraints on top of RFC 5444 constraints makes future designs harder (that is almost a tautology). Similarly, placing RFC 5444 constraints has itself made future designs more difficult. On other hand, there's a lot of protocols out there that have positional constraints (at all layers!) and we know how to do that. In particular, AODV (the experimental protocol) did not seem to encounter any difficulty with extensions, many of which never made it to the IETF, and I don't remember any complaint about the positional nature of AODV parameters in the message formats until this discussion. So, for all practical purposes, the argument that "positional =3D=3D bad" simply does not match my experience. As in many situations, each design deserves its own consideration. If positional designs make the packets smaller, that deserves to be considered, especially for wireless. I remember some recent discussion that there are more processor cycles than battery lifetime, which would motivate saving bytes over the air. It is always a tradeoff. > > That is maybe because the protocols were not implemented widely. > however, It is good that we now think in that direction for future > protocols in IETF. If this is a serious feature that is needed before we go forward with next steps, I can try to compose some specification language for it. I don't think it's too hard to do. -- = Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From abdussalambaryun@gmail.com Wed Jan 16 03:14:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC69621F8461 for ; Wed, 16 Jan 2013 03:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ7zovs6ngiH for ; Wed, 16 Jan 2013 03:14:18 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5721F845D for ; Wed, 16 Jan 2013 03:14:18 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id d16so1163925vcd.19 for ; Wed, 16 Jan 2013 03:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bVowWfhmZ8MaZKgGi7vXOQKj6XsKs7mFvx2VHl6HFu4=; b=WaJYSHtMt57eAX6ZfhQteoo3Ue7UKR4e77BeAWPbnOCdqHamUWQriAsvCMB7XnoCLB Rh8SEUV2xKc2rj8+9WJuwgSYL8kAjoWzKVMs0XYpXpyy1CVcd4z79STAyRGtG4HD5s0v iwJHaKfJH6hsc6dxyBnP8IRuIyIqFfZZpTGvUXml9KwppAyWEk7B3jMLT8+YvD0v3kYW JwMx+Wpd4ebkSHYKDg+PrvweQw257q9A3hlYcCqlysp5OVbon3UnlM+UsDYG4NC5waLa jwgat7MJtIYerzSS0746Bb4S2fKEyWIxdRq4GS9Xss26QsHeUUEhWFb4ru/t/LPW7h2Z FXLw== MIME-Version: 1.0 X-Received: by 10.52.76.170 with SMTP id l10mr554059vdw.83.1358334857337; Wed, 16 Jan 2013 03:14:17 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 16 Jan 2013 03:14:17 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> Date: Wed, 16 Jan 2013 12:14:17 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 11:14:19 -0000 >> Similarly, placing RFC 5444 constraints has itself made future designs >> more difficult. > > In what ways? IMO, RFC5444 made future manet-messaging design more flexible, and more interoperable, but the protocol design more difficult. No advantages come free I think, AB From charliep@computer.org Wed Jan 16 09:49:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ADC21F8B35 for ; Wed, 16 Jan 2013 09:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mc56UjGLgZC for ; Wed, 16 Jan 2013 09:49:20 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6E521F8717 for ; Wed, 16 Jan 2013 09:49:20 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvX70-0006hp-Ra; Wed, 16 Jan 2013 12:49:19 -0500 Message-ID: <50F6E81A.9050802@computer.org> Date: Wed, 16 Jan 2013 09:49:14 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e93beb9e853fdf1f628edba8da1cdafe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:49:21 -0000 Hello Chris, Short question -- potentially very long answer. But the question cannot be answered to your satisfaction unless we are measuring "difficulty" by using the same metric, and considering designs from the same solution space. For instance if I say that RFC 5444 makes designs *of a certain class* more difficult, and you say those designs are *inadmissible*, did we get anywhere? So, measuring by difficult of understanding the design space, there is no doubt that RFC 5444 makes designs harder to understand. We've already covered the difficulty of avoiding header bloat. Remember SMURF? RFC 5444 imposed a ~40% header tax when address compression was unavailable -- at that time we were all dealing mostly with IPv4. The goal of address compression has been compromised by the unwritten expectation of conformance to existing parser constraints, so much so that now LOADng seems willing to forego the benefit. Which kind of difficulty were you most interested in? I can also write about how RFC 5444 makes things easier, but you didn't ask that question. On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote: > Charlie >> Similarly, placing RFC 5444 constraints has itself made future designs more difficult. > In what ways? > -- Regards, Charlie P. From sratliff@cisco.com Wed Jan 16 10:06:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3421F8B90 for ; Wed, 16 Jan 2013 10:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScsAjobL8FKP for ; Wed, 16 Jan 2013 10:06:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C61D321F8B8A for ; Wed, 16 Jan 2013 10:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2346; q=dns/txt; s=iport; t=1358359608; x=1359569208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=daTquj48Kj2l7JmnkDisxDzy7KGgxaeJvnUeuWu5+tw=; b=WCp8WWZdPsyu1zoh/QH/1ooGW8Md+2KAex2mFFE+ymr7o+w8sbH5rk9e zfu2r+W7IEkxQZUKfbEVDJQqBhucTguxYgxcH/SCOrVsroMC3t6t+IiOD OdaJfQeKix6saMeLOkGRlHSGZZjhWLphGBz3AIoGRlfxNgduX0uhmIrUh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAInr9lCtJV2c/2dsb2JhbABFvX8Wc4IeAQEBAwEBAQE3NAkCEAIBCBgKFBAnCyUCBA4FCBOHeAYMuH0EkFdhA6ZVgnWCJA X-IronPort-AV: E=Sophos;i="4.84,480,1355097600"; d="scan'208";a="163112103" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 16 Jan 2013 18:06:48 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0GI6mqs005169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 18:06:48 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 12:06:48 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN9BHMbJtZ+zulZEq9CpdJ9dTPlZhMpPGA Date: Wed, 16 Jan 2013 18:06:47 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> In-Reply-To: <50F6E81A.9050802@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C17DC50117D1443AFB7B70EF4EEB59C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:06:55 -0000 On Jan 16, 2013, at 12:49 PM, Charles E. Perkins wrote: >=20 > Hello Chris, >=20 > Short question -- potentially very long answer. >=20 > But the question cannot be answered to your satisfaction unless > we are measuring "difficulty" by using the same metric, and > considering designs from the same solution space. >=20 > For instance if I say that RFC 5444 makes designs *of a certain > class* more difficult, and you say those designs are *inadmissible*, > did we get anywhere? >=20 > So, measuring by difficult of understanding the design space, > there is no doubt that RFC 5444 makes designs harder > to understand. >=20 > We've already covered the difficulty of avoiding header bloat. > Remember SMURF? RFC 5444 imposed a ~40% header tax > when address compression was unavailable -- at that time we > were all dealing mostly with IPv4. >=20 > The goal of address compression has been compromised by the > unwritten expectation of conformance to existing parser constraints, > so much so that now LOADng seems willing to forego the benefit. And this, IMO, is the crux of the issue in front of the WG. There is an exi= sting implementation (4 interoperable implementations, based on another thr= ead) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 use, = those implementations become non-compliant. So I think the real question(s)= should be:=20 - Do we as a WG want to force utilization of RFC5444 for the reactive proto= col, thereby losing the advantage of the existing interoperable implementat= ions?=20 - Or, is there a reasonable hybrid approach? To be honest, I'm much less concerned about header taxes, or how a given pa= rser scheme makes things easier in some ways, but harder in others. Regards, Stan >=20 > Which kind of difficulty were you most interested in? >=20 > I can also write about how RFC 5444 makes things easier, but > you didn't ask that question. >=20 > On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote: >> Charlie >>> Similarly, placing RFC 5444 constraints has itself made future designs = more difficult. >> In what ways? >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Wed Jan 16 10:21:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A0E21F8BED for ; Wed, 16 Jan 2013 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Riz71CF8cMfF for ; Wed, 16 Jan 2013 10:21:11 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8689821F8859 for ; Wed, 16 Jan 2013 10:21:11 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so196428vbi.8 for ; Wed, 16 Jan 2013 10:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yudt7WN7EI7Kqsga+C3+40Ea/AW5t+zeymjTctRs7tw=; b=LSVsbAy+1INDS1PBM6TC2fFk3Z/26sNQl1pZ3KBNKbZEepuCAWUWoXWhT+ZyrUhXOH iKmtuTPAP9rwzm6KWsUKMPcbt1vvsdKhfn3xp2hTMga6CvcDNmsOOZ8KSql9VyWrj7oJ 1vhvrGgpxVfpEwFrPeBn23oXwECZvxfmDc4x0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=yudt7WN7EI7Kqsga+C3+40Ea/AW5t+zeymjTctRs7tw=; b=AcxaGxa8Dy/Nhqka84yms1CtkPfTbQb5LsS+a13JPplpqWQSGXkGo8HDzv2g5iV2Xe PQDcek7E9xqhjuwB3cUHdw4TtpGHqbOALtB+go3oLGm3MTJaUHHmFzCuQo8MZreTAoMO qe3gr2oVlQrrkFqLuS5bwGA+nmt5Jk5R8Qc50BUuitudHVdqBkMMYMNfoHDB6cnA+W3Y 9UYkoqEeaLDOJ28Oq8Tgirw2ed7e+3McLa8MuO27NLf5YX5G9g48P+5XwZMleStRoF7G T4J/Usyjq1skf9Nlbj9ag0pE0HbHGmYUXOxXu2vBc377iAucChxWmUBN+qjsuUfuGnuS VnFg== MIME-Version: 1.0 X-Received: by 10.52.30.108 with SMTP id r12mr2061478vdh.72.1358360470727; Wed, 16 Jan 2013 10:21:10 -0800 (PST) Received: by 10.220.5.16 with HTTP; Wed, 16 Jan 2013 10:21:10 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> Date: Wed, 16 Jan 2013 10:21:10 -0800 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf307c9b9055acaa04d36bf182 X-Gm-Message-State: ALoCoQlPripbPwrsEGG5lazy6uxVv2ZDCJAQvTHLeommjKMg4UlOoC8bAex4Al39ZfrmYx07BGu3 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:21:14 -0000 --20cf307c9b9055acaa04d36bf182 Content-Type: text/plain; charset=ISO-8859-1 Stan, both Fujitsu's implementation and the one from LIX use RFC5444 in the way LOADng specifies it. I let Hitachi speak for their implementation. Do we really want to reopen the consensus of the WG to use RFC5444 for MANET routing protocols, and thus need to obsolete RFC5498? I think that would be a huge mistake. Best regards Ulrich On Wed, Jan 16, 2013 at 10:06 AM, Stan Ratliff (sratliff) < sratliff@cisco.com> wrote: > > On Jan 16, 2013, at 12:49 PM, Charles E. Perkins wrote: > > > > > Hello Chris, > > > > Short question -- potentially very long answer. > > > > But the question cannot be answered to your satisfaction unless > > we are measuring "difficulty" by using the same metric, and > > considering designs from the same solution space. > > > > For instance if I say that RFC 5444 makes designs *of a certain > > class* more difficult, and you say those designs are *inadmissible*, > > did we get anywhere? > > > > So, measuring by difficult of understanding the design space, > > there is no doubt that RFC 5444 makes designs harder > > to understand. > > > > We've already covered the difficulty of avoiding header bloat. > > Remember SMURF? RFC 5444 imposed a ~40% header tax > > when address compression was unavailable -- at that time we > > were all dealing mostly with IPv4. > > > > The goal of address compression has been compromised by the > > unwritten expectation of conformance to existing parser constraints, > > so much so that now LOADng seems willing to forego the benefit. > > And this, IMO, is the crux of the issue in front of the WG. There is an > existing implementation (4 interoperable implementations, based on another > thread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 > use, those implementations become non-compliant. So I think the real > question(s) should be: > > - Do we as a WG want to force utilization of RFC5444 for the reactive > protocol, thereby losing the advantage of the existing interoperable > implementations? > - Or, is there a reasonable hybrid approach? > > To be honest, I'm much less concerned about header taxes, or how a given > parser scheme makes things easier in some ways, but harder in others. > > Regards, > Stan > > > > > Which kind of difficulty were you most interested in? > > > > I can also write about how RFC 5444 makes things easier, but > > you didn't ask that question. > > > > On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote: > >> Charlie > >>> Similarly, placing RFC 5444 constraints has itself made future designs > more difficult. > >> In what ways? > >> > > > > > > -- > > Regards, > > Charlie P. > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307c9b9055acaa04d36bf182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stan,

both Fujitsu's implementation and the one from LIX use RFC= 5444 in the way LOADng specifies it. I let Hitachi speak for their implemen= tation.

Do we really want to reopen the consensus of the WG to use R= FC5444 for MANET routing protocols, and thus need to obsolete RFC5498? I th= ink that would be a huge mistake.

Best regards
Ulrich

On Wed, Jan 16= , 2013 at 10:06 AM, Stan Ratliff (sratliff) <sratliff@cisco.com>= wrote:

On Jan 16, 2013, at 12:49 PM, Charles E. Perkins wrote:

>
> Hello Chris,
>
> Short question -- potentially very long answer.
>
> But the question cannot be answered to your satisfaction unless
> we are measuring "difficulty" by using the same metric, and<= br> > considering designs from the same solution space.
>
> For instance if I say that RFC 5444 makes designs *of a certain
> class* more difficult, and you say those designs are *inadmissible*, > did we get anywhere?
>
> So, measuring by difficult of understanding the design space,
> there is no doubt that RFC 5444 makes designs harder
> to understand.
>
> We've already covered the difficulty of avoiding header bloat.
> Remember SMURF? =A0RFC 5444 imposed a ~40% header tax
> when address compression was unavailable -- at that time we
> were all dealing mostly with IPv4.
>
> The goal of address compression has been compromised by the
> unwritten expectation of conformance to existing parser constraints, > so much so that now LOADng seems willing to forego the benefit.

And this, IMO, is the crux of the issue in front of the WG. There is = an existing implementation (4 interoperable implementations, based on anoth= er thread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444= use, those implementations become non-compliant. So I think the real quest= ion(s) should be:

- Do we as a WG want to force utilization of RFC5444 for the reactive proto= col, thereby losing the advantage of the existing interoperable implementat= ions?
- Or, is there a reasonable hybrid approach?

To be honest, I'm much less concerned about header taxes, or how a give= n parser scheme makes things easier in some ways, but harder in others.

Regards,
Stan

>
> Which kind of difficulty were you most interested in?
>
> I can also write about how RFC 5444 makes things easier, but
> you didn't ask that question.
>
> On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote:
>> Charlie
>>> Similarly, placing RFC 5444 constraints has itself made future= designs more difficult.
>> In what ways?
>>
>
>
> --
> Regards,
> Charlie P.
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307c9b9055acaa04d36bf182-- From sratliff@cisco.com Wed Jan 16 10:39:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C4221F8B64 for ; Wed, 16 Jan 2013 10:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAiCP7Fq8o9X for ; Wed, 16 Jan 2013 10:39:26 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8CE21F8B73 for ; Wed, 16 Jan 2013 10:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8194; q=dns/txt; s=iport; t=1358361565; x=1359571165; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sj66jb0BxLGCIP6SEJ1Fdsr/vi2nW3VYmnfIvDTMfSs=; b=JEbeyebHc9ZAkIj964xPDLq4V7une5UH0DPspGsUnPdi+lYdWginmllw FVpKH0aI8370xoWgUwjtVdzP3sT6ijI/RPxVlEAtNOn4bH6V1xCqSR2Lo 3nJc38IM0Vh6U/xTqyGlj4x8SrRIe+Rb6vidLIaK3RHc+vA/1/ggfkRgB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIDy9lCtJV2Y/2dsb2JhbABFvX8Wc4IeAQEBAwEBAQFrCQIQAgEIGAodBycLFBECBA4FCBOHeAYMuHgEkFdhA4gsnimCdYIk X-IronPort-AV: E=Sophos;i="4.84,480,1355097600"; d="scan'208,217";a="163322157" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 16 Jan 2013 18:39:23 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0GIdN4l028864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 18:39:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 12:39:22 -0600 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN9BHMbJtZ+zulZEq9CpdJ9dTPlZhMpPGAgAAEBACAAAUWAA== Date: Wed, 16 Jan 2013 18:39:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF10F9@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF10F9xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:39:27 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF10F9xmbalnx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ulrich, Oh, good. I didn't realize a couple of the existing implementations use RFC= 5444. That pretty much solves my problem. Regards, Stan On Jan 16, 2013, at 1:21 PM, Ulrich Herberg wrote: Stan, both Fujitsu's implementation and the one from LIX use RFC5444 in the way L= OADng specifies it. I let Hitachi speak for their implementation. Do we really want to reopen the consensus of the WG to use RFC5444 for MANE= T routing protocols, and thus need to obsolete RFC5498? I think that would = be a huge mistake. Best regards Ulrich On Wed, Jan 16, 2013 at 10:06 AM, Stan Ratliff (sratliff) > wrote: On Jan 16, 2013, at 12:49 PM, Charles E. Perkins wrote: > > Hello Chris, > > Short question -- potentially very long answer. > > But the question cannot be answered to your satisfaction unless > we are measuring "difficulty" by using the same metric, and > considering designs from the same solution space. > > For instance if I say that RFC 5444 makes designs *of a certain > class* more difficult, and you say those designs are *inadmissible*, > did we get anywhere? > > So, measuring by difficult of understanding the design space, > there is no doubt that RFC 5444 makes designs harder > to understand. > > We've already covered the difficulty of avoiding header bloat. > Remember SMURF? RFC 5444 imposed a ~40% header tax > when address compression was unavailable -- at that time we > were all dealing mostly with IPv4. > > The goal of address compression has been compromised by the > unwritten expectation of conformance to existing parser constraints, > so much so that now LOADng seems willing to forego the benefit. And this, IMO, is the crux of the issue in front of the WG. There is an exi= sting implementation (4 interoperable implementations, based on another thr= ead) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 use, = those implementations become non-compliant. So I think the real question(s)= should be: - Do we as a WG want to force utilization of RFC5444 for the reactive proto= col, thereby losing the advantage of the existing interoperable implementat= ions? - Or, is there a reasonable hybrid approach? To be honest, I'm much less concerned about header taxes, or how a given pa= rser scheme makes things easier in some ways, but harder in others. Regards, Stan > > Which kind of difficulty were you most interested in? > > I can also write about how RFC 5444 makes things easier, but > you didn't ask that question. > > On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote: >> Charlie >>> Similarly, placing RFC 5444 constraints has itself made future designs = more difficult. >> In what ways? >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF10F9xmbalnx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1EEEC6194190A1408FCF90AFAAA63D64@cisco.com> Content-Transfer-Encoding: quoted-printable Ulrich, 

Oh, good. I didn't realize a couple of the existing implementations us= e RFC 5444. That pretty much solves my problem. 

Regards,
Stan

On Jan 16, 2013, at 1:21 PM, Ulrich Herberg wrote:

Stan,

both Fujitsu's implementation and the one from LIX use RFC5444 in the way L= OADng specifies it. I let Hitachi speak for their implementation.

Do we really want to reopen the consensus of the WG to use RFC5444 for MANE= T routing protocols, and thus need to obsolete RFC5498? I think that would = be a huge mistake.

Best regards
Ulrich

On Wed, Jan 16, 2013 at 10:06 AM, Stan Ratliff (= sratliff) <sratliff@cisco.com> wrote:

On Jan 16, 2013, at 12:49 PM, Charles E. Perkins wrote:

>
> Hello Chris,
>
> Short question -- potentially very long answer.
>
> But the question cannot be answered to your satisfaction unless
> we are measuring "difficulty" by using the same metric, and<= br> > considering designs from the same solution space.
>
> For instance if I say that RFC 5444 makes designs *of a certain
> class* more difficult, and you say those designs are *inadmissible*, > did we get anywhere?
>
> So, measuring by difficult of understanding the design space,
> there is no doubt that RFC 5444 makes designs harder
> to understand.
>
> We've already covered the difficulty of avoiding header bloat.
> Remember SMURF?  RFC 5444 imposed a ~40% header tax
> when address compression was unavailable -- at that time we
> were all dealing mostly with IPv4.
>
> The goal of address compression has been compromised by the
> unwritten expectation of conformance to existing parser constraints, > so much so that now LOADng seems willing to forego the benefit.

And this, IMO, is the crux of the issue in front of the WG. There is an exi= sting implementation (4 interoperable implementations, based on another thr= ead) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 use, = those implementations become non-compliant. So I think the real question(s) should be:

- Do we as a WG want to force utilization of RFC5444 for the reactive proto= col, thereby losing the advantage of the existing interoperable implementat= ions?
- Or, is there a reasonable hybrid approach?

To be honest, I'm much less concerned about header taxes, or how a given pa= rser scheme makes things easier in some ways, but harder in others.

Regards,
Stan

>
> Which kind of difficulty were you most interested in?
>
> I can also write about how RFC 5444 makes things easier, but
> you didn't ask that question.
>
> On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote:
>> Charlie
>>> Similarly, placing RFC 5444 constraints has itself made future= designs more difficult.
>> In what ways?
>>
>
>
> --
> Regards,
> Charlie P.
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF10F9xmbalnx03ciscoc_-- From hrogge@googlemail.com Wed Jan 16 11:07:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC8C21F87FB for ; Wed, 16 Jan 2013 11:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOI6Yameqmxb for ; Wed, 16 Jan 2013 11:07:42 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1377921F87DC for ; Wed, 16 Jan 2013 11:07:41 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fj20so1769567lab.24 for ; Wed, 16 Jan 2013 11:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Vm2R46kS3ZfBSt1ikMiG0fjL83C0YOxrXporX2GRr9g=; b=YcA9XfiNZeaPevzuuVxdiwB78clnbKbzZmrK64wiZdMmJyqiv51PSIDOyRSjzwLJw/ tJNnKGnBBRjOenMia1btnO43DNH/nVg4DeO5pLQuYm/syzpwE9ZXIIYzSXzn8q3+YGEN R3rs1aeO7sLxk+wi0cPjQoNOcSh0BbHpMuZnkPPhsQ20+9ZH5/1uTUAe19scRbNP3fSQ fQW9oSWTSMeYNYMY964n5qV9n84WcqUmKh4C+sj2NOLBA5rYdMc8FU7SPZh7UD2kuV3h KZy0iBuB9uly5QkhGpCa7kd+M+II75RhC8X/yv9sfXkJ3QRYIOWAE7F1rMBJMrH1Kgxm EZhQ== X-Received: by 10.112.11.68 with SMTP id o4mr1082799lbb.128.1358363260807; Wed, 16 Jan 2013 11:07:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Wed, 16 Jan 2013 11:07:20 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Wed, 16 Jan 2013 20:07:20 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:07:43 -0000 On Wed, Jan 16, 2013 at 7:06 PM, Stan Ratliff (sratliff) wrote: > And this, IMO, is the crux of the issue in front of the WG. There is an e= xisting implementation (4 interoperable implementations, based on another t= hread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 use= , those implementations become non-compliant. So I think the real question(= s) should be: > > - Do we as a WG want to force utilization of RFC5444 for the reactive pro= tocol, thereby losing the advantage of the existing interoperable implement= ations? I think instead of loosing the flexibility of RFC5444 in on the protocol level, we should have a look at XML schema based compression. I think we can adapt this approach to RFC5444 based MANET protocols, which would allow to further compress the packets down based on the necessities of the deployments. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Wed Jan 16 11:59:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3CA21F8AE7 for ; Wed, 16 Jan 2013 11:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X24HruAfdVYe for ; Wed, 16 Jan 2013 11:59:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C485421F8AE6 for ; Wed, 16 Jan 2013 11:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1358366391; x=1359575991; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HWH/enX5uLUm1SmfHxmnjXbHUq31yffSyw+wgdEjXPM=; b=Hb2Pjsyzp4tmfMzA2M3LjdrAt/9W9byeT9eXXxcvZsoulnR+5RJuGh0k SSE3OLyqPhMY+c6QDvAgimi37L7ocw+e6DPw0P2w/PBNLYHUdOxBuWftk kjdIKQ2cozhCtwXGakvLyrKMjxnfAgYZ5zHWnNsIiSmL24T4xEa0r4JhW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL8F91CtJV2b/2dsb2JhbABEvX8Wc4IeAQEBAwEBAQE3NAkCBQsCAQgOCgoUECcLJQIEDgUIiAsGDLkYBJBXYQOmVYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,480,1355097600"; d="scan'208";a="160390850" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jan 2013 19:59:51 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0GJxpIL006916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 19:59:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 13:59:51 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN9BHMbJtZ+zulZEq9CpdJ9dTPlZhMpPGAgAAQ6wCAAA6rAA== Date: Wed, 16 Jan 2013 19:59:50 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF14C9@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:59:52 -0000 Henning,=20 On Jan 16, 2013, at 2:07 PM, Henning Rogge wrote: > On Wed, Jan 16, 2013 at 7:06 PM, Stan Ratliff (sratliff) > wrote: >> And this, IMO, is the crux of the issue in front of the WG. There is an = existing implementation (4 interoperable implementations, based on another = thread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 us= e, those implementations become non-compliant. So I think the real question= (s) should be: >>=20 >> - Do we as a WG want to force utilization of RFC5444 for the reactive pr= otocol, thereby losing the advantage of the existing interoperable implemen= tations? >=20 > I think instead of loosing the flexibility of RFC5444 in on the > protocol level, we should have a look at XML schema based compression. > I think we can adapt this approach to RFC5444 based MANET protocols, > which would allow to further compress the packets down based on the > necessities of the deployments. That's an interesting idea. Also, since Ulrich pointed out that the existin= g LOADng implementations are indeed based on RFC 5444, I don't have an issu= e - I'd vote for full 5444 compliance, since that's already mandated for *r= outing protocols* (referencing our earlier DLEP discussion), and the reacti= ve protocol definitely applies.=20 Regards, Stan >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Jan 16 12:26:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7421F88CA for ; Wed, 16 Jan 2013 12:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MAujAJb9ORB for ; Wed, 16 Jan 2013 12:26:58 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id D221E21F8812 for ; Wed, 16 Jan 2013 12:26:57 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id gj3so1317400lbb.25 for ; Wed, 16 Jan 2013 12:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=+HrpQ8bvKbjCLFHuk1VaydK36phlJFBp/AexDug2orw=; b=JO39Ss74jgSk9WHUaJiCsZ+VFgqFEvaz3WV6Xj99qhKq+mAZo2Uozs0XMPjNnvHvpa YXuo9hJ4IIhsdYFClh5+jt8HIhQ0IW2TuRNDJnrQaF4R7eNjtAOof37dOYM62jkhXRIf nhhnqRMGJ+9xUrLTw7ZQcjWYIg62izelVhBrBNrRY3s8Ei8MwiskBvTNG8aTfyAv6Y9n dT/nNxjgJsD+e0GwT5krl7ZeWSM/7h8Ic4eKoeNGrij3D6F7eHFXAuxdKkmd7JHyKDpx fXjxID3Qo9aSH7t60Hty4L2n1kVHz/r+K1srsMmaqSWhobH3lUtTeLoAQGkLUwE8n3X0 l6XQ== X-Received: by 10.152.113.165 with SMTP id iz5mr2390962lab.50.1358368016745; Wed, 16 Jan 2013 12:26:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Wed, 16 Jan 2013 12:26:35 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF14C9@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF14C9@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Wed, 16 Jan 2013 21:26:35 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:26:58 -0000 On Wed, Jan 16, 2013 at 8:59 PM, Stan Ratliff (sratliff) wrote: >> I think instead of loosing the flexibility of RFC5444 in on the >> protocol level, we should have a look at XML schema based compression. >> I think we can adapt this approach to RFC5444 based MANET protocols, >> which would allow to further compress the packets down based on the >> necessities of the deployments. > > That's an interesting idea. Thank you. We plan to write it down (maybe as a IETF draft) and get a prototype. I think this has the potential to reduce RFC5444 packets even more without the need to touch the protocol (or maybe even the implementation!). > Also, since Ulrich pointed out that the existing LOADng implementations a= re indeed based on RFC 5444, I don't have an issue - I'd vote for full 5444= compliance, since that's already mandated for *routing protocols* (referen= cing our earlier DLEP discussion), and the reactive protocol definitely app= lies. *nod* Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Wed Jan 16 15:07:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020D811E80A6 for ; Wed, 16 Jan 2013 15:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYJTkBGULn1j for ; Wed, 16 Jan 2013 15:07:18 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4928111E809A for ; Wed, 16 Jan 2013 15:07:18 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so1883817vbn.14 for ; Wed, 16 Jan 2013 15:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dNo4TUKxAfy1mIg0BQ9V33tI76lcT0ceR4E10mPkHn0=; b=uWhk5lBtRcQeYZ0HNUSzqjZQe2kjqd+pKRvpSYhefl43Mq0J4Q827NRTauCecI5ea1 ujcyLCVYhAeK4hxxAa+2M01k3B3BOwznW5AP/srgwuX4P33CZTSda5LqYTTD/yMw04RK 3BIPOF0u2Y8bFuQEXkFv4Gxy6k0Ky7puzhAVYgzQ/hGT4HTcJZwYH6qpHlfumsZ+be0i DrRzSeOE3ntl64jVAEKwiowXIYIiuo+Y70b0acz9E/HRdguEjwi4SP2ahvPzSpIPCT2M ieiATlJZGLTjm8d8HFpsKbGrXmhhnBrMDRl5HMFzuMLrW7jct5ddS7HE1e+vnnfWW3ZF sphQ== MIME-Version: 1.0 X-Received: by 10.52.76.73 with SMTP id i9mr2841834vdw.25.1358377637599; Wed, 16 Jan 2013 15:07:17 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 16 Jan 2013 15:07:17 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> Date: Thu, 17 Jan 2013 00:07:17 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:07:19 -0000 Hi Henning, I am not sure I understand the example you made, could you give a suggestion of better design of RREQ and RREP for AODVv2 so we can reasonably go through the protocol functionality. Giving general exmples will not produce protocols for our WG, even the RFC5444 is flexibile but let us go through the reactive protocol messaging and its reflection on the function, not just giving interesting things outside the function, as compressing, AB On 1/16/13, Henning Rogge wrote: > On Wed, Jan 16, 2013 at 7:06 PM, Stan Ratliff (sratliff) > wrote: >> And this, IMO, is the crux of the issue in front of the WG. There is an >> existing implementation (4 interoperable implementations, based on another >> thread) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 >> use, those implementations become non-compliant. So I think the real >> question(s) should be: >> >> - Do we as a WG want to force utilization of RFC5444 for the reactive >> protocol, thereby losing the advantage of the existing interoperable >> implementations? > > I think instead of loosing the flexibility of RFC5444 in on the > protocol level, we should have a look at XML schema based compression. > I think we can adapt this approach to RFC5444 based MANET protocols, > which would allow to further compress the packets down based on the > necessities of the deployments. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Wed Jan 16 15:09:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0A11E80E2 for ; Wed, 16 Jan 2013 15:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9+dU0FAh82Z for ; Wed, 16 Jan 2013 15:09:12 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 981D411E80D9 for ; Wed, 16 Jan 2013 15:09:12 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id fa15so1927446vbb.1 for ; Wed, 16 Jan 2013 15:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LDMskZMlBRkmH7CQH2+iNy/xlbCfP0zy9G3Js5+SDzo=; b=cQ9lS1JT/v7ONoD6l2fvwKWkfVxJtNGCIN+f7QZgRHYtjd/WNWXEcq7jxXFTBoU8xn HZ1WjMEn8JCQ+QwD5Dp8ENWVOI5eum5kVynBBkcxnJssNSK/X9Q5d+vE9UZuQ8lYCWGk yFTkq8L9mk4iXLZYIlxzo2tWvFDNVj3mkRFSF88Fc5diwS9qNiv6azxV/795Id6FVZG7 YlR9uhCJKSxzmoKRQFmxzJz5z3jKmZI+nCMBm1WuC6jNdStMg5zigLM/WKmoZOPDgVlc vPv9Sw4VHfi6t91qdTDJfhtEe4/jrvEfh3/2ujTi/2WsWwVK/3a3qUE2OWMTdxDxbOy4 4fiw== MIME-Version: 1.0 X-Received: by 10.52.70.46 with SMTP id j14mr2762927vdu.99.1358377751913; Wed, 16 Jan 2013 15:09:11 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 16 Jan 2013 15:09:11 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF14C9@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF14C9@xmb-aln-x03.cisco.com> Date: Thu, 17 Jan 2013 00:09:11 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:09:13 -0000 Hi stan, > That's an interesting idea. Also, since Ulrich pointed out that the existing > LOADng implementations are indeed based on RFC 5444, I don't have an issue - > I'd vote for full 5444 compliance, since that's already mandated for > *routing protocols* (referencing our earlier DLEP discussion), and the > reactive protocol definitely applies. Do you mean that DYMO document is not full compliant of 5444 and LOADng is full complaint, please explain, because I disagree, AB From charliep@computer.org Wed Jan 16 15:17:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C48611E80E2 for ; Wed, 16 Jan 2013 15:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI-9TjaU8i7F for ; Wed, 16 Jan 2013 15:17:11 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 79A2011E80ED for ; Wed, 16 Jan 2013 15:17:08 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvcEG-00037q-CB; Wed, 16 Jan 2013 18:17:08 -0500 Message-ID: <50F734E9.7040701@computer.org> Date: Wed, 16 Jan 2013 15:16:57 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> In-Reply-To: <50F6614B.5060909@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86a4002b78cfec907debce388856c870b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:17:15 -0000 Hello Henning, On 1/16/2013 12:14 AM, Henning Rogge wrote: > > just compare RFC5444 to a piece of XML. I agree this is a very good comparison. > >> But what if a "clean protocol design" is measured by requiring >> fewer "special case" TLVs? > > If this is the case, why did we ever moved to a TLV format? Binary > format with most things defined by their order (and not a type) are > clearly "less overhead". People, including me, use TLVs because they are great for many purposes. Please note that there is no problem to have positional information in TLVs. > > But they can be a pain to extend later. Binary format is harder to read, that is sure. But TLVs can obviously be also in "binary format". > >> I really don't think that using the same design philosophy as has been >> used in hundreds of successful protocols should be called a "hack", >> and it certainly isn't "special" in that context. > > How many of them are TLV based formats? Given that TLVs can be (i) binary and (ii) positional, I'm not sure exactly what you are asking, and I do not know just what the percentages are. But, Mobile IP and Diameter use TLVs. > >> What about people >> who think RFC 5444 is a "hack", because there are ever more cases >> that require two-byte overhead here, two-byte overhead there, >> defining a new "hack" TLV when simple positional description would >> do? If they disappear from [manet] because their design ideas are >> labeled as "hacks", did RFC 5444 "win"? > > I am not aware of protocols leaving [manet] after RFC5444 got finalized. Well, there have been various complaints about [manet] headers being "too big". And, anyway, I was asking theoretical questions, about which I'd still like to know your opinion. > >> Moreover, as I understand it, it's not even just about RFC 5444, >> but about on the one hand conforming to someone's existing >> parser, and denigrating the word "positional". >> >>> This "positional information" is just a step backward to the packet >>> formats we had with AODV and OLSRv1. >> >> I'm not so sure which direction is forward. Anyway I hope it is >> clear that the overhead in the typical IPv6 RREQ/RREP case is >> much more than "2 bytes". > > After looking into the RREP specification in the current draft of > AODVv2, it might be even less than 2 bytes to skip the "position > information"... it could be zero bytes. > > The following is just an example for the RREP what we could do to get > rid of it. > > The RREP contains two addresses, both already "tagged" with an address > block TLV. > > We could easily take two message specific Address Block TLVs, one > called "Route Generation Sequence number" and one called "Route > Request Sequence Number" (the first one is similar to the Answer Set > Number of OLSRv2). > > This would allow AODVv2 to differentiate between your originator and > target address by looking at the TLV. This would be fine with me. It's encoding the positional information into the AddrTLV instead of the AddrBlk. One still has to know which address is which, so the new AddrTLV definitions would have to cover the case when both addresses have SeqNum. We could have four AddrTLV definitions: - Single SeqNum for Originator Address - Single SeqNum for Target Address - Two SeqNums, Originator Address first - Two SeqNums, Target Address first I'm fine with this, because I see no urgency in preserving AddrTLV numbering space. However, I'm not very clear about which design is "cleaner". > > (it might also allow nodes with multiple local addresses to reply to a > route request with more than one address, just by tagging multiple > addresses with the corresponding TLV) Well, if we're really dealing with an exponential increase in AddrTLV type definitions, I'm not sure about what's better. Or maybe I am missing some other way of doing the positional encoding. -- Regards, Charlie P. From abdussalambaryun@gmail.com Wed Jan 16 15:41:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77C711E810B for ; Wed, 16 Jan 2013 15:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRP2d1w2CEyn for ; Wed, 16 Jan 2013 15:41:08 -0800 (PST) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 63BE711E80FB for ; Wed, 16 Jan 2013 15:41:08 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id fy7so1906216vcb.6 for ; Wed, 16 Jan 2013 15:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jcsSrypPSs5b6kQi6ryXgB43SwlKPidwixiosEOnQdY=; b=thdo67ExbuKgMRP9EiCMn2CIQsYZrPs+WQVo0a+zcuNZg0+AL65iAiQrFSpoTzom/G d3ds5jTwMOMfs6W8MCo6e9xJpsCb3ik373oVdQgIznfnxKkFsLP7abL6jSw7m7/TkCV/ 7k6xcKDIb29spjRh4LeKg9BzGndy5PAHByndhB/HyDFrboZGQg3vkz3MQAfrbPtW1oji rLrkIc3tLTMBNpKDpPxU3uBAt3yzGQ+TWozRGbIvXd8JO/b/0zUaHHwEJ5pqr7sOQF7T 1xMCIVmXWrR7/5KSMQ1qRkRP0Gx8nMYDQZAm9ozFIEDTT5boQ3NoVO1NKp5okKnKZbrM 0qKQ== MIME-Version: 1.0 X-Received: by 10.52.21.179 with SMTP id w19mr2934177vde.55.1358379667664; Wed, 16 Jan 2013 15:41:07 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 16 Jan 2013 15:41:07 -0800 (PST) In-Reply-To: <50F734E9.7040701@computer.org> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> Date: Thu, 17 Jan 2013 00:41:07 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:41:10 -0000 > Given that TLVs can be (i) binary and (ii) positional, I'm not sure > exactly what you are asking, and I do not know just what the > percentages are. But, Mobile IP and Diameter use TLVs. > I agree with the above, but we may add (iii) random order TLVs in 5444 message, which I think prefered by Henning, AB From charliep@computer.org Wed Jan 16 16:22:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98F11E80EA for ; Wed, 16 Jan 2013 16:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt+h3j+fDBYe for ; Wed, 16 Jan 2013 16:22:20 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id CF71211E809C for ; Wed, 16 Jan 2013 16:22:19 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvdFK-0005Ii-HQ; Wed, 16 Jan 2013 19:22:18 -0500 Message-ID: <50F74435.1070405@computer.org> Date: Wed, 16 Jan 2013 16:22:13 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86db611f99d64e15c1f8bd070876d398a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 00:22:21 -0000 Hello Abdussalam and all, Yes, I certainly agree that TLVs can have the non-positional feature favored by Henning and Ulrich. Regards, Charlie P. On 1/16/2013 3:41 PM, Abdussalam Baryun wrote: >> Given that TLVs can be (i) binary and (ii) positional, I'm not sure >> exactly what you are asking, and I do not know just what the >> percentages are. But, Mobile IP and Diameter use TLVs. >> > I agree with the above, but we may add (iii) random order TLVs in 5444 > message, which I think prefered by Henning, > > AB > -- Regards, Charlie P. From abdussalambaryun@gmail.com Wed Jan 16 16:59:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1C811E809A for ; Wed, 16 Jan 2013 16:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU9OaOSPkDSj for ; Wed, 16 Jan 2013 16:59:47 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3D21F875C for ; Wed, 16 Jan 2013 16:59:46 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fl15so1973928vcb.18 for ; Wed, 16 Jan 2013 16:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qJxkjxa/J7ttUhhyKP1yo8I12+Hc3lz3DGVRX/EbsnA=; b=h3A8as4aVMeDfMa9SQPySPxmLo8hH42WMwwrq3v4EfLrALoB/KZCb3sLdYREA2Gypz 7IMfO/thIPp2GZkdtdkERINGSS6z0uXny+wJq7Jj7wEyQsRmxjyU47Wsp1YnFzUUcr7g NLZRoU5JA9p7uBCtAda7MmuxZt/UMTPycEga38WfGjt3PYVFy3QhUpgXNxU8Pbmro0Et DImIaeDADq6QW2m7mqH4Xn/QacFVgjJ0rCcS8EE0xIWLa9bBE+aNTNPwODkyD/hD/zGc cF+CUu5CcP1K5eDecZYiX533iE2aN3+9Aw2NsBL+5PjgL0y0zq8mzrRxMMjYtkUxslQ9 ndfQ== MIME-Version: 1.0 X-Received: by 10.220.107.5 with SMTP id z5mr3551472vco.22.1358384386206; Wed, 16 Jan 2013 16:59:46 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 16 Jan 2013 16:59:45 -0800 (PST) In-Reply-To: <50F74435.1070405@computer.org> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F74435.1070405@computer.org> Date: Thu, 17 Jan 2013 01:59:45 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 00:59:47 -0000 Hi Charlie, and All For me I don't much care about the way the message is formatted as long the protocol targets its functions at best for all its scenarios. The RFC5444 specifies that it is for the protocol to chose the way of its messages. The OLSRv2 was done its 5444-messages in such method for its purposes. Now we need to find the best way for our new reactive protocol 5444-messages, but to faivor its functions best not the best of hybrid routing with OLSRv2. I prefer we find a different way which is best of format the reactive TLVs in its rfc5444-message, and the message in the rfc5444-packet. Abdussalam Baryun, University of Glamorgan, UK On 1/17/13, Charles E. Perkins wrote: > Hello Abdussalam and all, > > Yes, I certainly agree that TLVs can have the non-positional feature > favored by Henning and Ulrich. > > Regards, > Charlie P. > > > On 1/16/2013 3:41 PM, Abdussalam Baryun wrote: >>> Given that TLVs can be (i) binary and (ii) positional, I'm not sure >>> exactly what you are asking, and I do not know just what the >>> percentages are. But, Mobile IP and Diameter use TLVs. >>> >> I agree with the above, but we may add (iii) random order TLVs in 5444 >> message, which I think prefered by Henning, >> >> AB >> > > > -- > Regards, > Charlie P. > > From shares@ndzh.com Wed Jan 16 17:19:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196411E80A6 for ; Wed, 16 Jan 2013 17:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6h0iGXzg-2t for ; Wed, 16 Jan 2013 17:19:37 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91D11E809C for ; Wed, 16 Jan 2013 17:19:36 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Henning Rogge'" , "'Charles E. Perkins'" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> In-Reply-To: <50F502A6.2010402@fkie.fraunhofer.de> Date: Wed, 16 Jan 2013 20:19:33 -0500 Message-ID: <002901cdf450$b5886bb0$20994310$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHudT1uDINtjmojwEwHKsjhtjvdPwHRflryApinT5kCcrN/6gM4TVV2A4Sb2okBswFHKAE44h6SAmw8laYCFvx8mgEovOEZAf0bD/wB/dVwTAIg2blsAbvazfkB2pMXZZcMi26g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:19:38 -0000 Henning and Charlie: Sorry for delay in responding.... =20 The 10.0.0.0/8 example will occur in the wild. People will pull out = their manet router with factory defaults.=20 I have seen routing policy that forbids 10.0.0.0/8 in a network = (Henning's example).=20 I have also seen Charlie's example where the people blocked each other. I'm sorry to be dense here. Your two behaviors simply restate the basics = of routing and policy. If you allow external route or static route insertion, these are = possible.=20 I thought the answer you both gave me was: 1) this is insertion of routes into reactive protools is useful but = hard,=20 2) current manet protocols will go on without prefix insertion,=20 3) We'll work next on as a specific topic.=20 I look forward to working on the route insertion at the right time with = both of you. Sue -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: Tuesday, January 15, 2013 2:18 AM To: Charles E. Perkins Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification On 01/15/2013 08:07 AM, Charles E. Perkins wrote: > Or, to say it the other way around -- as long as the nodes aren't=20 > advertising 0/0, no special care is needed except that the AODVv2=20 > routers have to obey the universal rule for advertising a subnet=20 > prefix. I disagree. (example below) >>> - Who is installing? >> >> Could be done by the administrator during the setup of the node. > > As currently specified, AODVv2 does not require any such extra=20 > installation instructions. Only the address -- that's it. > >> >> Something like "this subnet is reserved for host routes, install a=20 >> blackhole route to get no-route-available events". > > Yes, that is exactly my point. Something like that, or something like = > one of the other half-dozen ways of fixing the problem. Which shows that there IS a problem. >>> - What about a scenario when previously unrelated nodes decide to >>> form an ad hoc network? >>> What if all they bring to the network is their address or=20 >>> subnet, >> >> Where do they get the address/subnet from? If they all have the same=20 >> subnet, they could easily install a blackhole route for it. > > Please say more about what the requirements are when there are > 50 nodes, 10 of which lie on a subnet, and one of the nodes can have=20 > an Internet connection when necessary. > > How many nodes get exactly which blackhole route? > Do they all need the same network administrator? >>> except for perhaps a very few that can occasionally establish an >>> expensive link to the Internet? >> >> I don't think building a network of nodes by different parties and=20 >> giving all of them a totally random network address is a good idea. > > Well, it absolutely does work. Which doesn't make it a good idea in my opinion. Especially not if you = want to support any kind of gateway/prefix announcement. A better way might be to switch to IPv6 and get your random addresses = from a global /64 prefix... less chance to get a collision AND an easy way to prevent shorter prefixes to block your host routes. >>> I'm certainly willing to agree that with enough administrative=20 >>> control and policy knobs, one can make default routes work. Is this = >>> also your viewpoint? >> >> Its not only default routes, its any kind of routes. > > For all other routes likely to be encountered, the noted phenomenon of = > gateway congestion is quite unlikely to occur. > >> If you have a node that announces a prefix which overlaps with=20 >> host-routes of the network, you are in trouble in reactive protocols. > > A router can't advertise a prefix unless it guarantees the ability to=20 > reach nodes with addresses on that prefix. > Otherwise, the router is just spreading falsehoods and bad things can=20 > happen. Just because it's an ad hoc network does not mean that a node = > in the network can wreck the addressing convention of the address=20 > family from which it takes addresses. Lets take an example. A network of mesh nodes with random addresses. One of them is also attached to a local ethernet with the the configured prefix 10.0.0.0/8 (a common prefix for a home network) and wants this = nodes to be available on the mesh. If it publishes this prefix, it could block other nodes who randomly got allocated a host address from this range. --- The other way around, if all your nodes grab their random IP address from 10.0.0.0/8, its easy = to forbid prefixes to be announced from this range AND install a blackhole route for 10.0.0.0/8, so even shorter prefixes cannot block the "still = to be discovered" host routes of the mesh. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From shares@ndzh.com Wed Jan 16 17:30:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3DF11E80A6 for ; Wed, 16 Jan 2013 17:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.666 X-Spam-Level: X-Spam-Status: No, score=0.666 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnB9zG7dawc6 for ; Wed, 16 Jan 2013 17:30:54 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A5A0811E809C for ; Wed, 16 Jan 2013 17:30:54 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Charles E. Perkins'" , "'Henning Rogge'" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <50F514D5.1030204@computer.org> In-Reply-To: <50F514D5.1030204@computer.org> Date: Wed, 16 Jan 2013 20:30:49 -0500 Message-ID: <002e01cdf452$497eba30$dc7c2e90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHudT1uDINtjmojwEwHKsjhtjvdPwHRflryApinT5kCcrN/6gM4TVV2A4Sb2okBswFHKAE44h6SAmw8laYCFvx8mgEovOEZAf0bD/wB/dVwTAIg2blsAbvazfkB2pMXZQLN9C8xlvYpF3A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Spam:******, Re: Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:30:55 -0000 Charlie and Henning: Perhaps I don't understand your posts, but as far as I can tell you are discussion two sides of the same problem. Charlie says: [snip] a) it can't publish the prefix if it doesn't own the prefix. b) you can't mix random addressing and subnets. This is because subnets "own" their address range. Somehow I feel I must be missing your point. [snip] I have seen two nodes publish prefixes they claim to own based on static route insertion policy. (See the SIDR discussion on prefix/Origin AS mapping. ) The point I thought Henning was making is that it will happen so we need policy to deal with it. Charlie's point was it should not occur based on theory. Both are true, and should be considered as we work toward external route insertion. It is what makes this design so much fun. Sue [warning: I am not a zeroconf, netconf, or AODV2 expert] -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Charles E. Perkins Sent: Tuesday, January 15, 2013 3:36 AM To: Henning Rogge Cc: manet@ietf.org Subject: Spam:******, Re: [manet] Stability versus gateway specification Hello Henning, On 1/14/2013 11:17 PM, Henning Rogge wrote: > >>> >>> Something like "this subnet is reserved for host routes, install a >>> blackhole route to get no-route-available events". >> >> Yes, that is exactly my point. Something like that, or something >> like one of the other half-dozen ways of fixing the problem. > > Which shows that there IS a problem. Well... I'm not sure what you're saying here. I do not personally want to write the specification for advertising 0/0. I think it leads to problems that do not require a reactive-protocol-specific solution. You agree there is a problem. > >>> >>> Where do they get the address/subnet from? If they all have the same >>> subnet, they could easily install a blackhole route for it. >> >> Please say more about what the requirements are when there are >> 50 nodes, 10 of which lie on a subnet, and one of the nodes can have >> an Internet connection when necessary. >> >> How many nodes get exactly which blackhole route? >> Do they all need the same network administrator? > > > > >>>> except for perhaps a very few that can occasionally establish an >>>> expensive link to the Internet? >>> >>> I don't think building a network of nodes by different parties and >>> giving all of them a totally random network address is a good idea. >> >> Well, it absolutely does work. > > Which doesn't make it a good idea in my opinion. Especially not if you > want to support any kind of gateway/prefix announcement. I'd like to support Mobile IP in the ad hoc network... We did it before and it works great. I've already cited the document. And it works even if the gateway is advertising a prefix. These are by no means mutually exclusive functions. > > A better way might be to switch to IPv6 and get your random addresses > from a global /64 prefix... less chance to get a collision AND an easy > way to prevent shorter prefixes to block your host routes. If you're trying to convince me to re-run the playbook from the former [autoconf] working group, l will just for now claim that this proves my point that we should delay the matter. > >>>> I'm certainly willing to agree that with enough administrative >>>> control and policy knobs, one can make default routes work. Is >>>> this also your viewpoint? >>> >>> Its not only default routes, its any kind of routes. >> >> For all other routes likely to be encountered, the noted phenomenon >> of gateway congestion is quite unlikely to occur. > > >>> If you have a node that announces a prefix which overlaps with >>> host-routes of the network, you are in trouble in reactive protocols. >> >> A router can't advertise a prefix unless it guarantees the ability to >> reach nodes with addresses on that prefix. >> Otherwise, the router is just spreading falsehoods and bad things can >> happen. Just because it's an ad hoc network does not mean that a >> node in the network can wreck the addressing convention of the >> address family from which it takes addresses. > > Lets take an example. > > A network of mesh nodes with random addresses. > > One of them is also attached to a local ethernet with the the > configured prefix 10.0.0.0/8 (a common prefix for a home network) and > wants this nodes to be available on the mesh. The net-10 subnet wants its net-10 addressable nodes to be available for communications across the entire MANET, if I understand your hypothesis... > > If it publishes this prefix, it could block other nodes who randomly > got allocated a host address from this range. a) it can't publish the prefix if it doesn't own the prefix. b) you can't mix random addressing and subnets. This is because subnets "own" their address range. Somehow I feel I must be missing your point. Are we talking about net-10 allocations from several routers in the same MANET? Ouch-e-roonie (to use the technical terminology). NAT too? Pour me a double. > > The other way around, > > if all your nodes grab their random IP address from 10.0.0.0/8, its > easy to forbid prefixes to be announced from this range AND install a > blackhole route for 10.0.0.0/8, so even shorter prefixes cannot block > the "still to be discovered" host routes of the mesh. On which of the 50 nodes is the blackhole route installed? What if the net-10 router only comes up the day after tomorrow? Who's administering the other nodes? It's "easy" if there's a network administrator handy (not too ad-hoc). Actually, I'm not clear on your scenario, or even whether we mean the same thing by "blackhole route": http://en.wikipedia.org/wiki/Null_route And I am really not at all understanding why this is germane to what needs to be done soon for reactive routing protocol specification. -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From shares@ndzh.com Wed Jan 16 17:34:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F511E809C for ; Wed, 16 Jan 2013 17:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6n0WtkzT+ZN for ; Wed, 16 Jan 2013 17:34:09 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E50DE11E809A for ; Wed, 16 Jan 2013 17:34:08 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Abdussalam Baryun'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> <016101cdf267$8e973580$abc5a080$@ndzh.com> <017701cdf26a$2ed1d0d0$8c757270$@ndzh.com> <411154BD-93B4-43C7-8A6D-BDCD744A0F14@jiaziyi.com> <001601cdf281$c429a920$4c7cfb60$@ndzh.com> <38082A63-85B7-487E-B5A1-100A3983F81E@jiaziyi.com> <005d01cdf2c0$330e4bf0$992ae3d0$@ndzh.com> In-Reply-To: Date: Wed, 16 Jan 2013 20:34:05 -0500 Message-ID: <003001cdf452$bd70e300$3852a900$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQF+uLaWApiDCfMCQJPrkAJny71zAaMHyk4C+YlVfwFwxkc9Afx+wegCQ0nGEpgg5+8w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:34:09 -0000 AB: You got my meaning. IETF spec + 4 implementations + same net = working code Your correction : IETF spec + IETF 5444 protocol + IETF port x + 4 implementation + same net = working code. Thanks for helping me understand. Sue -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Tuesday, January 15, 2013 3:51 AM To: Susan Hares Cc: Jiazi Yi; manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) Hi Sue, Yes in your understanding it is ok, which I think any one on the list will think, but does thoes 4 routers with independent implementation can work together in same network. In my opinion if understanding independent the way you defined then they should work together as long they are following the same IETF draft specification. In other understandning of independent, which I think that poster ment by *independent*, that they cannot work together, because they yes follow the specification but they are implemented in different architecture layers. So to say they follow the specification but not all 4 implementation use the RFC5444's assigned port. However, I may be wrong, but just making sure I understand the meaning :) AB On 1/15/13, Susan Hares wrote: > AB: > > What I mean by independent implementations is that 4 different people > took the specification, and wrote the code from the specification. > The four people did not share their code with each other. > > This is different than 4 people taking one code base and modifying it. > > Sue > > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: Monday, January 14, 2013 1:45 PM > To: Jiazi Yi > Cc: Susan Hares; manet@ietf.org > Subject: Re: [manet] Hares technical question 1: Design of sequence > numbers (warning long post) > > On 1/14/13, Jiazi Yi wrote: >> For LOADng, which make use of this sequence number rotation, has at >> least 4 independent implementations. As far as I can see, I didn't >> notice > any issue. >> > > Do you mean four different implementation or independent > implementation. I understand the independent cannot work together (not > interoperable), or am I wrong, > > AB > > From shares@ndzh.com Wed Jan 16 17:41:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EED921F8634 for ; Wed, 16 Jan 2013 17:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZbjK5IQxtwb for ; Wed, 16 Jan 2013 17:41:27 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1389221F8633 for ; Wed, 16 Jan 2013 17:41:27 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Abdussalam Baryun'" , "'Henning Rogge'" References: <50F53CC2.6040205@fkie.fraunhofer.de> In-Reply-To: Date: Wed, 16 Jan 2013 20:41:23 -0500 Message-ID: <003601cdf453$c2736de0$475a49a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKnp72tcyoOPp+B55fw03qq/jtrogGMtsigAF9HvhsCVxHtbZZ3PzkQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:41:28 -0000 AB and Henning:=20 Let me confirm - these results are one implementation ported to four devices? =20 Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun Sent: Tuesday, January 15, 2013 6:35 AM To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code Hi Henning, thanks alot, but I think the tests reported by the doc is only for one implementation, not all 4 LOADng implementations, however, I will = contact the authors of the doc, thanks, AB On 1/15/13, Henning Rogge wrote: > On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: >> As you agree with RFC2026, I can understand you mean that the 4=20 >> implementation you refered to previously are interoperable, please=20 >> confirm, and that they may work together, > > Maybe this will answer your question? I think this document was=20 > already mentioned on this list. > > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-re > port-04 > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 > Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 > Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20 > Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Wed Jan 16 17:47:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3AD21F861A for ; Wed, 16 Jan 2013 17:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3ijmwdwRW8R for ; Wed, 16 Jan 2013 17:47:53 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0166E21F8615 for ; Wed, 16 Jan 2013 17:47:50 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TveZy-0004Ih-4Y; Wed, 16 Jan 2013 20:47:42 -0500 Message-ID: <50F75839.5000104@computer.org> Date: Wed, 16 Jan 2013 17:47:37 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Susan Hares References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> In-Reply-To: <002901cdf450$b5886bb0$20994310$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d84bb28cd69b084ed5aa007cd912a3b9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:47:53 -0000 Hello Sue, I am fine with your three points. The WG manet protocols are applicable to networks for which the nodes populating the networks are known to have unique addresses. So it would probably break the WG specifications to have non-unique net-10 addresses. I think that it probably makes sense to improve the "Applicability Statement" to restrict AODVv2 for deployment only in networks where the nodes have unique IP addresses. Regards, Charlie P. On 1/16/2013 5:19 PM, Susan Hares wrote: > Henning and Charlie: > > Sorry for delay in responding.... > > The 10.0.0.0/8 example will occur in the wild. People will pull out their > manet router with factory defaults. > > I have seen routing policy that forbids 10.0.0.0/8 in a network (Henning's > example). > I have also seen Charlie's example where the people blocked each other. > > I'm sorry to be dense here. Your two behaviors simply restate the basics of > routing and policy. > If you allow external route or static route insertion, these are possible. > > I thought the answer you both gave me was: > > 1) this is insertion of routes into reactive protools is useful but hard, > 2) current manet protocols will go on without prefix insertion, > 3) We'll work next on as a specific topic. > > I look forward to working on the route insertion at the right time with both > of you. > > > Sue > > -- Regards, Charlie P. From shares@ndzh.com Wed Jan 16 17:49:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208C921F861A for ; Wed, 16 Jan 2013 17:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v74qd-XtQuMU for ; Wed, 16 Jan 2013 17:49:24 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 22AB021F862B for ; Wed, 16 Jan 2013 17:49:18 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Dearlove, Christopher \(UK\)'" , "'Thomas Heide Clausen'" , "'Ulrich Herberg'" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> In-Reply-To: Date: Wed, 16 Jan 2013 20:49:12 -0500 Message-ID: <003a01cdf454$d9f90be0$8deb23a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJisPCRMT8vkNWydoI1/6vlGuxC1QIYjcQ0AfyrF8oBcD5iiAFRD6Z1AeY5OX8CD3bcW5bM5J9w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:49:25 -0000 Chris: Have you discussed these scenarios at an IETF or on the list? If so, = can you point me to the IETF presentation or list day.=20 If not, there is considerable complexity behind your suggestion. =20 Have you or the group done a literature search on algorithms from sensor = and manet that examine this? I'm a bit out of date on sensors and = mobility (2-3 years on DC switches), but there used to be a lot of = challenge in these algorithms. =20 Charlie and Thomas used to entertain me with ideas a few years ago.=20 I'm not saying that considering this wouldn't be fun though, Cheers,=20 Sue=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Dearlove, Christopher (UK) Sent: Tuesday, January 15, 2013 8:22 AM To: Thomas Heide Clausen; Ulrich Herberg Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker To my mind, a critical question is whether an RREQ or an RREP might, at = some point, carry more than one address in what is the main address = category. Could an RREQ carry more than one address "I'm looking for A and/or B"? = (and/or, as I could see either being a possibility). Could an RREP carry more than one address - either "you asked for A, I = am A. I'm also B, C and D" or with IRREPs "I also route to B, C and D". This sort of information could be flagged with TLVs. Positionally it's = much harder - especially if we may want to add such cases later. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks = and Image Analysis Capability BAE Systems Advanced Technology Centre = West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 = chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales = No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Thomas Heide Clausen Sent: 11 January 2013 16:50 To: Ulrich Herberg Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. -------------------------------------------------------- In complete agreement with Ulrich here.=20 Associating semantics to ordering of TLVs or addresses in 5444 removes = the ability for generic parsers and generators. That would be a very = unfortunate design, given that 5444 was designed exactly to be generic. Thomas Sent from my iPad On 11 janv. 2013, at 08:25, Ulrich Herberg wrote: > I agree with Henning. A protocol using RFC5444 should not mandate a = certain order or a split into address blocks for the reasons Henning = mentioned. The RFC5444 parser/generator can be independent of the = protocol that uses it (in my LOADng code that's the case), and used by = several protocol implementations and extensions concurrently. The = protocols and extensions may not necessarily have the information about = positions or split into address blocks. >=20 > In LOADng, no such knowledge is required. >=20 > Regards > Ulrich >=20 > On Jan 10, 2013, at 23:03, Henning Rogge = wrote: >=20 >> On 01/10/2013 08:42 AM, Charles E. Perkins wrote: >>> Hello Henning, >>>=20 >>> I'll put the issue on the Issue Tracker tomorrow. >>>=20 >>> However, there have been many protocols using positional information = >>> for lists (of addresses, etc) without impairment of extensibility. >>> This is especially true when extensions go at the end. Do you have=20 >>> any particular example in mind where RFC 5444 somehow creates a=20 >>> problem with this? >>=20 >> With NHDP, OLSRv2 and LOADng its trivial to extend the protocol = because I can just add whatever I want to the protocol message, as long = as I use new TLVs. >>=20 >> New addresses? No problem, regardless on the position. >>=20 >> New TLVs on existing addresses? No problem too. >>=20 >> Why use a pure TLV format if we put parts of the information into the = order and structure of the format and do NOT use TLVs for it? >>=20 >> The restriction of the order of addresses and the mandatory split = into multiple address blocks is also a problem for address compression. = The order and split have a huge influence on the compression efficiency, = demanding a specific split/order will make AODVv2 messages larger in = some cases. >>=20 >> Henning Rogge >>=20 >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr=20 >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 = Wachtberg,=20 >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.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://www.ietf.org/mailman/listinfo/manet From shares@ndzh.com Wed Jan 16 17:50:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61121F86B2 for ; Wed, 16 Jan 2013 17:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrrk9XUK3Dl1 for ; Wed, 16 Jan 2013 17:50:50 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C6CDD21F861A for ; Wed, 16 Jan 2013 17:50:48 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> <012801cdf263$14855960$3d900c20$@ndzh.com> <50F417E4.8070304@fkie.fraunhofer.de> In-Reply-To: Date: Wed, 16 Jan 2013 20:50:45 -0500 Message-ID: <003c01cdf455$114403c0$33cc0b40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLNxnmL6cVAglJr/WkVENy2ida7LwH+PYT4Aw9Wjq8BafpM+wKExXcPlgU6WiA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:50:52 -0000 Chris: Could you verify it today? I'm writing up some comments for KARP for Stewart Bryant, and I'd like to include it in my email. Thanks, Sue=20 -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Tuesday, January 15, 2013 8:39 AM To: Henning Rogge; Susan Hares Cc: manet@ietf.org Subject: RE: [manet] Hares Technical Issue 4 - GTSM I think perhaps the correct place is actually 5498 rather than 5444. = (5498 mandates - on the manet port/protocol - that which 5444 provides as a proposed usage.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks = and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 = chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: = 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: 14 January 2013 14:36 To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM On 01/14/2013 03:26 PM, Susan Hares wrote: > Henning: > > Again, thank you for aiding my understanding. > > Do I understand from this message that RFC5444 should be the protocol=20 > running GTSM? Yes, I think GTSM is a security consideration (and option) for RFC5444. So AODVv2 could suggest using it for RFC5444, but I don't think its the place to mandate its usage. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From shares@ndzh.com Wed Jan 16 17:54:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F2511E809C for ; Wed, 16 Jan 2013 17:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.645 X-Spam-Level: X-Spam-Status: No, score=0.645 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUlDDYdBjbqf for ; Wed, 16 Jan 2013 17:54:12 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF9A11E80DE for ; Wed, 16 Jan 2013 17:54:12 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Dearlove, Christopher \(UK\)'" References: <000501cdf214$7df68cb0$79e3a610$@ndzh.com> <50F3B07E.7040806@fkie.fraunhofer.de> <012401cdf262$2625ca20$72715e60$@ndzh.com> <50F41A84.1080904@fkie.fraunhofer.de> In-Reply-To: Date: Wed, 16 Jan 2013 20:54:09 -0500 Message-ID: <003e01cdf455$8a9069d0$9fb13d70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8QWJsm0wlMWv+DYmOs3+mrx3sLAJf6lDwAhbWy3sCY8bUDQGpVZiamKwIpWA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence numbers (warning long post) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 01:54:13 -0000 Chris: Thanks for letting me know the technical problem is real. Code tends = to favor the last received, but that choice is not 100% deterministic (as I think Charlie said).=20 I still have not had time to read Hennings code. I'm hoping I learn a = bit from the code. Sue=20 -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Tuesday, January 15, 2013 8:43 AM To: Henning Rogge; Susan Hares Cc: manet@ietf.org Subject: RE: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) The case S1 and S2 differ by MAXVALUE / 2 is indeterminate. There's = actually a technical problem is you define it, as then A can supersede B can supersede A. You're probably better off keeping the older/newer item as determined by order of reception, not serial number. OLSRv2 says this = case is up to you. What it doesn't say is that if you ever see it smething somewhere is broken and is likely to make a mess of things. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks = and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 = chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: = 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: 14 January 2013 14:48 To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares technical question 1: Design of sequence = numbers (warning long post) Sorry for not the bad answer to your first mail. See explanation = below... On 01/14/2013 03:19 PM, Susan Hares wrote: > Henning: > > Thank you for the quick response. Below I have the text sections from > > http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt > > How should I interpret this text? Your comment is > > -1 (0xFFFF), 0, 1 > > How does it work? > > Let us assume S1 rotates through MAX_VALUE (0xFFFF, 0, 1) , and S2=20 > stays at 0xCFFF. > > The sequence numbers are broken in half so MAX_VALUE/2 =3D 0x7FFF Step = > 1; If S1=3D 0xFFFF and S2 =3D 0xCFFF > S1-S2 =3D 0x3000, and less than 0x7FFF - therefore S1 is > S2 > > Step 2: If S1=3D0x0000 and S2 =3D 0xCFFF, S1-S2 =3D 0x3001, therefore = s1 is=20 > > S2 Step 3: If S1 =3D 0x7FFF and S2 =3D 0xCFFF, S2-S1 =3D 0x5000 > = 0x3FFF=20 > Step 4: If S1 =3D 0xCFFF and S2 =3D 0xCFFF S1-S2 =3D 0 , and no case = > follows >> The sequence number S1 is said to be "greater than" (denoted '>') = >> the sequence number S2 if: >> S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > = MAXVALUE/2 If this formula is "true", S1 is considered larger than S2. If this formula is "false", S1 is considered to be smaller than S2. Its a single boolean formula, no "two cases". @Ulrich Herberg: maybe the formula could be presented like this to make it more clear? (S2 < S1 AND S1 - S2 <=3D MAXVALUE/2 OR S1 < S2 AND S2 - S1 > MAXVALUE/2) Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From ulrich@herberg.name Wed Jan 16 18:14:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508A31F0CAF for ; Wed, 16 Jan 2013 18:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91ACSVOK-vps for ; Wed, 16 Jan 2013 18:14:29 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id CBE671F0C3E for ; Wed, 16 Jan 2013 18:14:29 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id v40so849810dad.22 for ; Wed, 16 Jan 2013 18:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NokOw8W8WXspXXX0llTyIkt4ni3cb7ATiOI12c2LQPs=; b=bjp861PM4nqGeprfZZ9Y5UT1rAaA7xsh4u2SQIyxOwQ9OlFRKIfFgt5ihkKxEPzfSs WBfHoEURXnuB05P+9Unx1OTvJnqcTpBQzLGsHAgiLJixw76Urj3Ge04U99sYt0Vn3qXR lAWLRv8XM8MpSKP3J+W3g/O/QUj+blRyRfVqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=NokOw8W8WXspXXX0llTyIkt4ni3cb7ATiOI12c2LQPs=; b=OKKMH9/YvP8UF4aAMgNItDrrF4+u7MnkbzGgCYUtCS+4zmNoc3ZLOrhLWPFG7c4JzH i6h7y4rkfuOzUarDkhi/Cjuxd1yowzeWr6MzJWKLjoiobjm4OtB6dRxhfF+SHz1sw8jY SmufltegmMWBE5Rd5qguYEvb6S7mWKoPEVl7Mb/SRfZ9DfdfrgfXt1Wyjjj9FNJWzvkC WHYX+ASZB1ysh4/mJV9h4+V2keeCpyTmn9hZYqy/8nED8+Osng9TxoZfLY8C2cz/t9q2 6YgoUaT/2TZhD3/i9egqj3Pr7uqGv8cKoyCHybypZwZQArc+5mWKK3nL9FfLPxB5Ic7I 1k9w== MIME-Version: 1.0 X-Received: by 10.66.80.202 with SMTP id t10mr8962115pax.81.1358388869328; Wed, 16 Jan 2013 18:14:29 -0800 (PST) Received: by 10.68.197.5 with HTTP; Wed, 16 Jan 2013 18:14:29 -0800 (PST) In-Reply-To: <003601cdf453$c2736de0$475a49a0$@ndzh.com> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> Date: Wed, 16 Jan 2013 18:14:29 -0800 Message-ID: From: Ulrich Herberg To: Susan Hares Content-Type: multipart/alternative; boundary=f46d042ef4ff05ef3e04d3728e9f X-Gm-Message-State: ALoCoQncKmuEIxZS8t6WTqG2P3197UG/WVNAmuIcMokwJIo+q/gZUN5TmsGBr9GuhhVBIm1bg/L1 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 02:14:31 -0000 --f46d042ef4ff05ef3e04d3728e9f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sue, these are four different implementations, developed independently from different companies / universities. Best regards Ulrich On Wed, Jan 16, 2013 at 5:41 PM, Susan Hares wrote: > AB and Henning: > > Let me confirm - these results are one implementation ported to four > devices? > > Sue > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: Tuesday, January 15, 2013 6:35 AM > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Router's Implemetation and Running Code > > Hi Henning, > > thanks alot, but I think the tests reported by the doc is only for one > implementation, not all 4 LOADng implementations, however, I will contact > the authors of the doc, thanks, > > AB > > On 1/15/13, Henning Rogge wrote: > > On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: > >> As you agree with RFC2026, I can understand you mean that the 4 > >> implementation you refered to previously are interoperable, please > >> confirm, and that they may work together, > > > > Maybe this will answer your question? I think this document was > > already mentioned on this list. > > > > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-re > > port-04 > > > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, > > Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d042ef4ff05ef3e04d3728e9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sue,

these are four different implementations, developed independent= ly from different companies / universities.

Best regards
Ulrich <= br>
On Wed, Jan 16, 2013 at 5:41 PM, Susan Ha= res <shares@ndzh.com> wrote:
AB and Henning:

Let me confirm - these results are one implementation ported to four
devices?

Sue

-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of
Abdussalam Baryun
Sent: Tuesday, January 15, 2013 6:35 AM
To: Henning Rogge
Cc: manet@ietf.org
Subject: Re: [manet] Router's Implemetation and Running Code

Hi Henning,

thanks alot, but I think the tests reported by the doc is only for one
implementation, not all 4 LOADng implementations, however, I will contact the authors of the doc, thanks,

AB

On 1/15/13, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
> On 01/15/2013 12:14 PM, Abdussalam Baryun wrote:
>> As you agree with RFC2026, I can understand you mean that the 4 >> implementation you refered to previously are interoperable, please=
>> confirm, and that they may work together,
>
> Maybe this will answer your question? I think this document was
> already mentioned on this list.
>
> http://tools.ietf.org/html/draft-lavenu-lln-= loadng-interoperability-re
> port-04
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, > Germany
> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
> mailto:henning.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d042ef4ff05ef3e04d3728e9f-- From henning.rogge@fkie.fraunhofer.de Wed Jan 16 23:07:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15D21F8B45 for ; Wed, 16 Jan 2013 23:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IWQx7GIZOGv for ; Wed, 16 Jan 2013 23:07:24 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4621F8B49 for ; Wed, 16 Jan 2013 23:07:23 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TvjZA-0007Gi-Oo; Thu, 17 Jan 2013 08:07:12 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TvjZA-0004Vq-M7; Thu, 17 Jan 2013 08:07:12 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 17 Jan 2013 08:07:12 +0100 Message-ID: <50F7A31F.8070309@fkie.fraunhofer.de> Date: Thu, 17 Jan 2013 08:07:11 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles E. Perkins" References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> In-Reply-To: <50F734E9.7040701@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070102080900050203090809" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16509/Thu Jan 17 04:30:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 209e4906e65bf60adc8fc3e5a3b0b088 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 07:07:25 -0000 --------------ms070102080900050203090809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/17/2013 12:16 AM, Charles E. Perkins wrote: > People, including me, use TLVs because they are great for > many purposes. Please note that there is no problem to > have positional information in TLVs. To come back to XML, you would not do positional informations in XML...=20 and I think you shouldn't do this in RFC5444 either. >> How many of them are TLV based formats? > > Given that TLVs can be (i) binary and (ii) positional, I'm not sure > exactly what you are asking, and I do not know just what the > percentages are. But, Mobile IP and Diameter use TLVs. >>> What about people >>> who think RFC 5444 is a "hack", because there are ever more cases >>> that require two-byte overhead here, two-byte overhead there, >>> defining a new "hack" TLV when simple positional description would >>> do? If they disappear from [manet] because their design ideas are >>> labeled as "hacks", did RFC 5444 "win"? >> >> I am not aware of protocols leaving [manet] after RFC5444 got finalize= d. > > Well, there have been various complaints about [manet] headers > being "too big". And, anyway, I was asking theoretical questions, abou= t > which I'd still like to know your opinion. >> After looking into the RREP specification in the current draft of >> AODVv2, it might be even less than 2 bytes to skip the "position >> information"... it could be zero bytes. >> >> The following is just an example for the RREP what we could do to get >> rid of it. >> >> The RREP contains two addresses, both already "tagged" with an address= >> block TLV. >> >> We could easily take two message specific Address Block TLVs, one >> called "Route Generation Sequence number" and one called "Route >> Request Sequence Number" (the first one is similar to the Answer Set >> Number of OLSRv2). >> >> This would allow AODVv2 to differentiate between your originator and >> target address by looking at the TLV. > > This would be fine with me. It's encoding the positional information > into the AddrTLV > instead of the AddrBlk. One still has to know which address is which, > so the new > AddrTLV definitions would have to cover the case when both addresses > have SeqNum. No, it does not...i propose to use a DIFFERENT TLV for the "route=20 generation sequence number" and for the "route request sequence number". By this it encodes the same information without the need of any special=20 position. The implementation can easily decide for each address if its an=20 originator, a target or something else (to ignore the address) just by=20 looking WHICH TLV is attached to the address. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070102080900050203090809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTcwNzA3MTFaMCMGCSqGSIb3DQEJBDEWBBR4tOM6nAyVVYVjzZnLGH2xwh86RzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwOQaVZbmTU3HN3+Mt8D5KkJd5tqF0S742DLYPitlnKGE y4ujQ43WUkNliARhhJCf6+Vm+0p+ZT0nBguar0s7Y6zN4zUgCHLhP3yVwX3p3l7MXTYNwuuS NetZpu3eW52pIRGNkJxMuYa7xrsGrskNm6BPRd86gmjrv/LMb1VcBWrAAmor8TCsqC8toafP U3Z8LvLoqO2jkfjQwcaIX/gymrrZ7p/l6MWBUiiHDez+nWeKmit/jXgg+y/KoNsY9Ju1X6M8 9zWnZfZayZ4xiio66D3CREeIPnX15bQE8Gd7hHbiwJTt9QyHkFFAvyfAuPiOjh/T//0x/YFm 7G2G7O5YQgAAAAAAAA== --------------ms070102080900050203090809-- From henning.rogge@fkie.fraunhofer.de Wed Jan 16 23:23:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7922121F8614 for ; Wed, 16 Jan 2013 23:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOYRjpEWfiwd for ; Wed, 16 Jan 2013 23:23:04 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C121F8456 for ; Wed, 16 Jan 2013 23:23:04 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TvjoV-0003qh-NP for manet@ietf.org; Thu, 17 Jan 2013 08:23:03 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TvjoV-0004rL-Kk for manet@ietf.org; Thu, 17 Jan 2013 08:23:03 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 17 Jan 2013 08:23:03 +0100 Message-ID: <50F7A6D2.8010008@fkie.fraunhofer.de> Date: Thu, 17 Jan 2013 08:22:58 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000505060002050907050803" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16509/Thu Jan 17 04:30:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d11929bbb37d0bf82123645737fe3651 Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 07:23:05 -0000 --------------ms000505060002050907050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/17/2013 12:07 AM, Abdussalam Baryun wrote: > Hi Henning, > > I am not sure I understand the example you made, could you give a > suggestion of better design of RREQ and RREP for AODVv2 so we can > reasonably go through the protocol functionality. > > Giving general exmples will not produce protocols for our WG, even the > RFC5444 is flexibile but let us go through the reactive protocol > messaging and its reflection on the function, not just giving > interesting things outside the function, as compressing, I was talking about a potential new Draft for this working group which=20 defines a transparent compression/decompression scheme for RFC5444 messag= es. I think this is "in scope" of this WG. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000505060002050907050803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTcwNzIzMDFaMCMGCSqGSIb3DQEJBDEWBBTKp67oyW1kKRrHVg7/lP+O3cQWCjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAZzVRMRncsTs/h0AGd8KU/iKNw5GmofBM46f59oI5dmmH zi+A64MpGs9OqPnu81jfpnC0CuKHIotRJkF2qwOJTbbWb8r/jlrUWhH+grxoGztC+Rd/8F1q K9vkgdiMXfH6xBksyuUlrS7QoPCGBe6k84MMGzbSdTUOb/aG+z0NbIkxOvTMeeLYyfuXlDsi O//TGXpPrB+iJ7e/5YNa5P7pmm35XPKLkL4g6ihHvEE1QN3dSl3eoFSfi0jFWhMO090S6FYL 21Ev7jgjvs3w3j+MxeeAANtsNBQFTerpiReeI8WQWBG3vrrBPYGLbV/kCfiar5ObDvGhW4Q3 ERyi9A68DwAAAAAAAA== --------------ms000505060002050907050803-- From abdussalambaryun@gmail.com Wed Jan 16 23:57:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ABA21F8629 for ; Wed, 16 Jan 2013 23:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfBF8j1q1EHn for ; Wed, 16 Jan 2013 23:57:41 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id DC29B21F841B for ; Wed, 16 Jan 2013 23:57:40 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so763728vbi.8 for ; Wed, 16 Jan 2013 23:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UHrRmxCWwnR36HG3NUR3tVS1R15Q7CspiyQGmp+jJtg=; b=NH9CbJHQCQ4eyNOh5K8hdSTrlU3445oaLZMtdPwGWJTxqyCYP6um1L+Awh/HAf0ZYK glxiZgYr6Vtmxr7cHrvlAjMAUJV5vICkaGEu3Tp9fFw0zJBT2Mj6Y8C4MVw7ylf9Fkq5 M0n2iN+pfvaps3LqpaTa889DYCvJkW3G3CjQEwsxV7dHdy4/32PB56XbkYY0RForgxUH bNM8SdM3Mm0jPAeFQUdK69WIQvu3Zfaf2BPq4s7ikyUV5CiB+xNgIWTKU1NkVEGyfa/B ASDkBSWuZn8XtF4b30HNKMlu1VW2yZB//ESunA0bGHFmfmrVOP3fdigLQOnW5ByOlIf1 /N7g== MIME-Version: 1.0 X-Received: by 10.52.175.106 with SMTP id bz10mr3816809vdc.125.1358409460264; Wed, 16 Jan 2013 23:57:40 -0800 (PST) Received: by 10.220.145.5 with HTTP; Wed, 16 Jan 2013 23:57:40 -0800 (PST) In-Reply-To: <003601cdf453$c2736de0$475a49a0$@ndzh.com> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> Date: Thu, 17 Jan 2013 08:57:40 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 07:57:41 -0000 Thanks Sue for your input, That was my understanding when read inteop-loadng draft before, just to add to you text *four different devices*, but will read again when I can. The authors confirmed that they documented it correctly, AB On 1/17/13, Susan Hares wrote: > AB and Henning: > > Let me confirm - these results are one implementation ported to four > devices? > > Sue > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: Tuesday, January 15, 2013 6:35 AM > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Router's Implemetation and Running Code > > Hi Henning, > > thanks alot, but I think the tests reported by the doc is only for one > implementation, not all 4 LOADng implementations, however, I will contact > the authors of the doc, thanks, > > AB > > On 1/15/13, Henning Rogge wrote: >> On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: >>> As you agree with RFC2026, I can understand you mean that the 4 >>> implementation you refered to previously are interoperable, please >>> confirm, and that they may work together, >> >> Maybe this will answer your question? I think this document was >> already mentioned on this list. >> >> http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-re >> port-04 >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Thu Jan 17 00:05:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957C21F8B5E for ; Thu, 17 Jan 2013 00:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2ggJbU+XCg9 for ; Thu, 17 Jan 2013 00:05:02 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 37F1121F8B37 for ; Thu, 17 Jan 2013 00:05:02 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id p1so2192163vcq.38 for ; Thu, 17 Jan 2013 00:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=xtJO7VfhC9I9D4ZjGjWUEL04Mk+4Zg1dBJnBFi0aIxI=; b=P0Uo0VSm4MHLvoolpVTa5707YLFHOknwsBt4pUj4kUFiExZyC5lFGMJx9DxXxQYWPP NO5gy8NhnFxnKsiTwOnf6z0bW3d/kGRcH2vdUviYIEMa1NOT1ggL8xY1hyW9jBZ1Gkm5 kzski5luu09XfEhy739O+ea9AyCbdgkYCo9MgDCwFXABpfWD9WD047XjRSdjaNd2wlba KoLkC2n276HcwF/nLM+qDQiIBb+JmY+CijLPwR5E4bwTv7dGg9s8Br2ZE83CP8i9hnQ0 UkO22O7JZYOHdRgBX4bDEtDHZ7hlQkU2w49RFJaFppn6WbUgN+NxLG2P8JFoKFFw0uc0 N8Hw== MIME-Version: 1.0 X-Received: by 10.52.175.106 with SMTP id bz10mr3832419vdc.125.1358409901470; Thu, 17 Jan 2013 00:05:01 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 00:05:01 -0800 (PST) Date: Thu, 17 Jan 2013 09:05:01 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: [manet] Defining a transparent compression/decompression scheme for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 08:05:03 -0000 Hi Henning, I agree that defining a scheme will be helpful for the use of RFC5444, but I think it should be an informational draft, Also maybe we can look through compression/decompression schemes for RFC5444, not only one scheme, AB Sub: Re: [manet] Notifications from the IETF tools Issue Tracker On 1/17/13, Henning Rogge wrote: > On 01/17/2013 12:07 AM, Abdussalam Baryun wrote: >> Hi Henning, >> >> I am not sure I understand the example you made, could you give a >> suggestion of better design of RREQ and RREP for AODVv2 so we can >> reasonably go through the protocol functionality. >> >> Giving general exmples will not produce protocols for our WG, even the >> RFC5444 is flexibile but let us go through the reactive protocol >> messaging and its reflection on the function, not just giving >> interesting things outside the function, as compressing, > > I was talking about a potential new Draft for this working group which > defines a transparent compression/decompression scheme for RFC5444 > messages. > > I think this is "in scope" of this WG. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From abdussalambaryun@gmail.com Thu Jan 17 00:10:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFD021F8B58 for ; Thu, 17 Jan 2013 00:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8I3iX3cbAJ9 for ; Thu, 17 Jan 2013 00:10:17 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id C81D121F88D8 for ; Thu, 17 Jan 2013 00:10:16 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id p16so2197809vcq.25 for ; Thu, 17 Jan 2013 00:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=8WodJFHOFSsmVGzkPXZforarRybRR+Z1g4skru7rZ6A=; b=LJzrJjQ+jyKs4r7ZG7FEuSqnRdNFwAmMmdLlByxwF/uCiG5K10BFgrm9+7shLfeU1d Jfac8sSl6X77WlVibFQfDB2ROpX/4WuA6TfjEhB8SFuU51yOhp83TXzcJm3rqLM9p8UX v6vkIXhCt1pzmb9xxDQNjcGrYeMbUt3jObiPei9rnWm0Ba0h/79lgvAw4TykknKfJD2E j0gPxL04S27RCRHwm+bjo+hRXPwfTgO8jVbhgoEo2IzpiYCMn+Mpdu0qZoFv9n10kKaI dA8LQ80335fPYE8/BCk6iLQvZm6d5nAMUSAdSrfDn0mRlrn4uCoVcALWccWz29hXq4HF jcsw== MIME-Version: 1.0 X-Received: by 10.220.115.20 with SMTP id g20mr4514794vcq.31.1358410216223; Thu, 17 Jan 2013 00:10:16 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 00:10:15 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Jan 2013 09:10:15 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Defining a transparent compression/decompression scheme for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 08:10:17 -0000 Any compression/decompression scheme for RFC5444 SHOULD not affect the generality of the RFC5444 standard, otherwise it will not be general. Another way to avoid confusion we may update the RFC5444 with a section explaining thoes schemes as optional schemes that make advantages for protocols, AB From abdussalambaryun@gmail.com Thu Jan 17 00:16:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7612A21F8B49 for ; Thu, 17 Jan 2013 00:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ya2-dasZu38 for ; Thu, 17 Jan 2013 00:16:37 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id BD46E21F8B3A for ; Thu, 17 Jan 2013 00:16:37 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fl15so2241322vcb.4 for ; Thu, 17 Jan 2013 00:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=7frHzn1TauQrJaatMnxe3t6PUU9VAqEb5xbDnF8Y7cY=; b=0uHXMfIMezW2EWJ5DhyTzKoSnTCbTU7cnSpNWhAYgjWZTSJcJR57jTzNah2URjla0z m5Mi8czoE7DBvMscHwRQp+zudIHMAbJNS+xeWHWqN3pV4LtZmzZb9KF3320XtnYF9w6m DzhGHtp4EOJuniogIr+/rgo1p2umhBa6B59J5MN++n4AqiVbtMN1GocGTqgTu1JTfljI sVjaHOfG7yT7j5ZNWr+gESkMbG/6T8YFj/0SBxpRi6NsJr+En9obBoF3KrEIax2Q5a9U IE3HPOeLBm5WAYvy+Y0gaYZKnt35NrjG/CdS9btVP4FrHPhFU41KailypminE0cW08HM pnKw== MIME-Version: 1.0 X-Received: by 10.52.27.50 with SMTP id q18mr4022301vdg.20.1358410597222; Thu, 17 Jan 2013 00:16:37 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 00:16:37 -0800 (PST) In-Reply-To: <50F7A31F.8070309@fkie.fraunhofer.de> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> Date: Thu, 17 Jan 2013 09:16:37 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 08:16:38 -0000 You can think that 5444-message information details is a language of routers as you refer to XML in comparing them. This will mean that that language is a general language because the 5444 is general language not specific, AB On 1/17/13, Henning Rogge wrote: > On 01/17/2013 12:16 AM, Charles E. Perkins wrote: >> People, including me, use TLVs because they are great for >> many purposes. Please note that there is no problem to >> have positional information in TLVs. > > To come back to XML, you would not do positional informations in XML... > and I think you shouldn't do this in RFC5444 either. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From thomas@thomasclausen.org Thu Jan 17 00:18:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3C821F883C for ; Thu, 17 Jan 2013 00:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsz-FvveodDT for ; Thu, 17 Jan 2013 00:18:09 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E0CAB21F8615 for ; Thu, 17 Jan 2013 00:18:09 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5E85BA5508 for ; Thu, 17 Jan 2013 00:18:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 36CCF1CC052D; Thu, 17 Jan 2013 00:18:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from 201-9.eduroam.saclay.inria.fr (nat-invites.saclay.inria.fr [195.83.213.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7ACE81CC052C; Thu, 17 Jan 2013 00:18:07 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: Date: Thu, 17 Jan 2013 09:18:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 08:18:10 -0000 Abdussalam, This is really incredible; did you actually _read_ the Interoperability = report? Please do so, before jumping to assumptions. For each interoperability event, there is a section "Participating = Implementations". Here's an example, snipped from the draft from the = _first_ interop test (when there were just 3 implementations - the = latter tests had 4). It is explicitly mentioned that in that test, = there's one Java implementation, one C implementation for an embedded = platform and one C++ implementation for MacOS. > 4.3. Participating Implementations >=20 >=20 > The following implementations were used to perform the > interoperability tests this section, listed alphabetically: >=20 > Ecole Polytechnique: "LIX" - This implementation was jointly > developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg = and > Thomas Clausen of Ecole Ploytechnique's networking team. It > consists of approximately 6000 lines of JAVA code running in a = Mac > OS environment. It supports RREQ, RREP, RREP-ACK and RERR > generation, processing, forwarding and transmission. >=20 > Hitachi YRL 1: "Hitachi 1" - This implementation was fully = developed > by Yuichi Igarashi of Hitachi YRL. It consists of 1589 lines of = C > code running in the Hitachi proprietary micro OS environment > embedded in a 16MHz H8 micro processor. It supports RREQ, RREP, > RREP-ACK and RERR generation, processing, forwarding and > transmission. >=20 > Hitachi YRL 2: "Hitachi 2" - This implementation was jointly > developed by Nobukatsu Inomata of Hitachi ULSI Systems and Yoko > Morii of Hitachi YRL. It consists of 1987 lines of C++ code > running in a Mac OS environment. It supports RREQ, RREP, = RREP-ACK > generation, processing, forwarding and transmission, and RERR > processing. Thomas On Jan 17, 2013, at 08:57 , Abdussalam Baryun = wrote: > Thanks Sue for your input, >=20 > That was my understanding when read inteop-loadng draft before, just > to add to you text *four different devices*, but will read again when > I can. The authors confirmed that they documented it correctly, >=20 > AB >=20 > On 1/17/13, Susan Hares wrote: >> AB and Henning: >>=20 >> Let me confirm - these results are one implementation ported to four >> devices? >>=20 >> Sue >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Abdussalam Baryun >> Sent: Tuesday, January 15, 2013 6:35 AM >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] Router's Implemetation and Running Code >>=20 >> Hi Henning, >>=20 >> thanks alot, but I think the tests reported by the doc is only for = one >> implementation, not all 4 LOADng implementations, however, I will = contact >> the authors of the doc, thanks, >>=20 >> AB >>=20 >> On 1/15/13, Henning Rogge wrote: >>> On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: >>>> As you agree with RFC2026, I can understand you mean that the 4 >>>> implementation you refered to previously are interoperable, please >>>> confirm, and that they may work together, >>>=20 >>> Maybe this will answer your question? I think this document was >>> already mentioned on this list. >>>=20 >>> = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-re >>> port-04 >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >>> Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Jan 17 00:52:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1D21F8609 for ; Thu, 17 Jan 2013 00:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lek0f3hWzwSk for ; Thu, 17 Jan 2013 00:52:58 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id C48BC21F8456 for ; Thu, 17 Jan 2013 00:52:58 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id ez10so2280568vbb.11 for ; Thu, 17 Jan 2013 00:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pKtOS2fUWa9ByN0EZksfiJhf2v7wAC8qPVbi/fn2I0k=; b=XJJZFpO/PAzRuJ2Kr/U92ruhpgk7m//XslxV0qUBtat70Oh7pJRl9Dl/T6teMXyCQx jU7mtbE89hmXU4yEXYSZqd9J09Yl4dK/afZj1gWfoMa+1P5CoCbzvAN8KWHFAo+SwWGZ n9i7vI+Xe0mpMzZUhK6nuvaZLuKl83HNuyXuXCBnwMAZO5ps4WmBOpyEccz5Y+h3LKwh 9bV/ELgI86kUxcmLYhG87wIacPEqpQc9Z96AMFzuicmOPfRkf+uw5xrQtMD83e5B2Pt2 eD8HGMFEVZBxE1umWjy+voy3SRv+8RM8J6mTmmp+ur2enYISy7hNL5duJ+KlR3i0Wrax QXRQ== MIME-Version: 1.0 X-Received: by 10.220.218.197 with SMTP id hr5mr4541085vcb.8.1358412778243; Thu, 17 Jan 2013 00:52:58 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 00:52:58 -0800 (PST) In-Reply-To: <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> Date: Thu, 17 Jan 2013 09:52:58 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 08:52:59 -0000 Hi Thomas, sorry for my understandning, but as you may know my English is not the first language and I am new in the IETF vocabulary, I like to learn and make things better, I beleive there are alot like me in the market that like your work and have some feedback, which I am doing my best. However, my comments/feedback in line, On 1/17/13, Thomas Heide Clausen wrote: > Abdussalam, > > This is really incredible; did you actually _read_ the Interoperability > report? Please do so, before jumping to assumptions. yes read quickly but not assuming what I understood it was realy what I felt, and just stated the fact of my first reading. I agree that I need to improve :) > > For each interoperability event, there is a section "Participating > Implementations". Here's an example, snipped from the draft from the _first_ > interop test (when there were just 3 implementations - the latter tests had > 4). It is explicitly mentioned that in that test, there's one Java > implementation, one C implementation for an embedded platform and one C++ > implementation for MacOS. So my understanding from your reply that the test were done within 4 different languages and environments. What about the implementor, were they in contact and followed a same director/advisor, were there an independance in implementing the understanding of specification. I think not documented so far in my reading. I may be wrong, please advise, AB From thomas@thomasclausen.org Thu Jan 17 01:48:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B872521F880F for ; Thu, 17 Jan 2013 01:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5E4l2JCnTws for ; Thu, 17 Jan 2013 01:48:09 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E1F2F21F8653 for ; Thu, 17 Jan 2013 01:48:09 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id DCBCBA3AD1 for ; Thu, 17 Jan 2013 01:48:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 781CF1BC5187; Thu, 17 Jan 2013 01:48:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.200.21.73] (nat-invites.saclay.inria.fr [195.83.213.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0F5B41BC5180; Thu, 17 Jan 2013 01:48:08 -0800 (PST) References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-378AC5DE-95C2-48AB-BA0E-BCC8D8F232D8 Message-Id: <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Thu, 17 Jan 2013 10:48:06 +0100 To: Abdussalam Baryun Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 09:48:10 -0000 --Apple-Mail-378AC5DE-95C2-48AB-BA0E-BCC8D8F232D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPad On 17 janv. 2013, at 09:52, Abdussalam Baryun w= rote: > Hi Thomas, >=20 > sorry for my understandning, but as you may know my English is not the > first language and I am new in the IETF vocabulary, I like to learn Nor is English my first language ;) > On 1/17/13, Thomas Heide Clausen wrote: >> Abdussalam, >>=20 >> This is really incredible; did you actually _read_ the Interoperability >> report? Please do so, before jumping to assumptions. >=20 > yes read quickly but not assuming what I understood it was realy what > I felt, and just stated the fact of my first reading. I agree that I > need to improve :) I recommend that, if you want to comment on a document, you read it carefull= y. It's not efficient to have to repeat things, which are already well docum= ented and in detail. >> For each interoperability event, there is a section "Participating >> Implementations". Here's an example, snipped from the draft from the _fir= st_ >> interop test (when there were just 3 implementations - the latter tests h= ad >> 4). It is explicitly mentioned that in that test, there's one Java >> implementation, one C implementation for an embedded platform and one C++= >> implementation for MacOS. >=20 > So my understanding from your reply that the test were done within 4 > different languages and environments. What about the implementor, were > they in contact and followed a same director/advisor, were there an > independance in implementing the understanding of specification. I > think not documented so far in my reading. As the implementations were done by different (and, in some cases, competing= ) corporate entities/companies, I would be quite surprised if the different e= ngineers had the same "director/advisor". This is also documented in the report (companies, and even people). Thomas > I may be wrong, please advise, >=20 > AB --Apple-Mail-378AC5DE-95C2-48AB-BA0E-BCC8D8F232D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPad

On 17 janv. 2013, at 09:52, Abdussalam Baryun &l= t;abdussalambaryun@gmail.com> wrote:

= Hi Thomas,

sorry for my u= nderstandning, but as you may know my English is not the
first language and I am new in the IETF vocabulary, I like to learn
Nor is English my first la= nguage ;)
<= br>
On 1/17/13, T= homas Heide Clausen <thomas@thomasclausen.org> wrote:
Abdussalam,
<= span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(255, 25= 5, 255, 0);">
This is really incredible; did you actually _= read_ the Interoperability
report? Please do so, before ju= mping to assumptions.

yes read q= uickly but not assuming what I understood it was realy what
I felt, and j= ust stated the fact of my first reading. I agree that I
need to improve := )

I recommend that, if you want to com= ment on a document, you read it carefully. It's not efficient to have to rep= eat things, which are already well documented and in detail.

<= blockquote type=3D"cite">For each interoperability event, there is a s= ection "Participating
= Implementations". Here's an example, snipped from the draft from the _= first_
interop t= est (when there were just 3 implementations - the latter tests had
4). It is explicitly men= tioned that in that test, there's one Java
implementation, one C implementation for an embe= dded platform and one C++
implementation for MacOS.

So my understanding from your reply that the test were do= ne within 4
different languages and environments. What= about the implementor, were
they in contact and follo= wed a same director/advisor, were there an
independanc= e in implementing the understanding of specification. I
think not documented so far in my reading.

As the implementations were done by different (and, i= n some cases, competing) corporate entities/companies, I would be quite surp= rised if the different engineers had the same "director/advisor".
=
This is also documented in the report (compa= nies, and even people).


= Thomas

I may be wrong, please advis= e,

AB
= --Apple-Mail-378AC5DE-95C2-48AB-BA0E-BCC8D8F232D8-- From Chris.Dearlove@baesystems.com Thu Jan 17 01:51:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178DB21F880F for ; Thu, 17 Jan 2013 01:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2rfX4mOE9Wk for ; Thu, 17 Jan 2013 01:51:39 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id D768521F8803 for ; Thu, 17 Jan 2013 01:51:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="301190785" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jan 2013 09:51:37 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0H9pZVm032486 for ; Thu, 17 Jan 2013 09:51:35 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3816056" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 17 Jan 2013 09:51:35 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 09:51:34 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAANuoAgAAsxwCAAAylgIAA5oQQgACHUACAAQwn0A== Date: Thu, 17 Jan 2013 09:51:34 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> In-Reply-To: <50F6E81A.9050802@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 09:51:40 -0000 I'm afraid I don't see anything concrete there. And when you say "there is = no doubt" I definitely don't agree. It's a matter of presentation. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Charles E. Perkins [mailto:charliep@computer.org] = Sent: 16 January 2013 17:49 To: Dearlove, Christopher (UK) Cc: Abdussalam Baryun; manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Chris, Short question -- potentially very long answer. But the question cannot be answered to your satisfaction unless we are measuring "difficulty" by using the same metric, and considering designs from the same solution space. For instance if I say that RFC 5444 makes designs *of a certain class* more difficult, and you say those designs are *inadmissible*, did we get anywhere? So, measuring by difficult of understanding the design space, there is no doubt that RFC 5444 makes designs harder to understand. We've already covered the difficulty of avoiding header bloat. Remember SMURF? RFC 5444 imposed a ~40% header tax when address compression was unavailable -- at that time we were all dealing mostly with IPv4. The goal of address compression has been compromised by the unwritten expectation of conformance to existing parser constraints, so much so that now LOADng seems willing to forego the benefit. Which kind of difficulty were you most interested in? I can also write about how RFC 5444 makes things easier, but you didn't ask that question. On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote: > Charlie >> Similarly, placing RFC 5444 constraints has itself made future designs m= ore difficult. > In what ways? > -- = Regards, Charlie P. ******************************************************************** 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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Jan 17 01:55:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8821F88A1 for ; Thu, 17 Jan 2013 01:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkTb7gZFFhNQ for ; Thu, 17 Jan 2013 01:55:36 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6C21221F86B7 for ; Thu, 17 Jan 2013 01:55:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="255725785" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jan 2013 09:55:35 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0H9tZHi029322 for ; Thu, 17 Jan 2013 09:55:35 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3593228" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 17 Jan 2013 09:55:35 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 09:55:34 +0000 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Charles E. Perkins" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAANuoAgAAsxwCAAAylgIAA5oQQgACHUACAAATngIABCAZg Date: Thu, 17 Jan 2013 09:55:34 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 09:55:37 -0000 We as a WG have already made a decision, ratified by the IESG etc., it's in= RFC 5498. I view with dismay some people's apparent attempts to unroll thi= s, and make yet more here unagreed. (Strictly, that decision applies only to protocols using the manet port/pro= tocol. But there it is necessary to be retained.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] = Sent: 16 January 2013 18:07 To: Charles E. Perkins Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Jan 16, 2013, at 12:49 PM, Charles E. Perkins wrote: > = > Hello Chris, > = > Short question -- potentially very long answer. > = > But the question cannot be answered to your satisfaction unless > we are measuring "difficulty" by using the same metric, and > considering designs from the same solution space. > = > For instance if I say that RFC 5444 makes designs *of a certain > class* more difficult, and you say those designs are *inadmissible*, > did we get anywhere? > = > So, measuring by difficult of understanding the design space, > there is no doubt that RFC 5444 makes designs harder > to understand. > = > We've already covered the difficulty of avoiding header bloat. > Remember SMURF? RFC 5444 imposed a ~40% header tax > when address compression was unavailable -- at that time we > were all dealing mostly with IPv4. > = > The goal of address compression has been compromised by the > unwritten expectation of conformance to existing parser constraints, > so much so that now LOADng seems willing to forego the benefit. And this, IMO, is the crux of the issue in front of the WG. There is an exi= sting implementation (4 interoperable implementations, based on another thr= ead) that, IIRC, do *not* use RFC5444. By forcing (via MUST) RFC 5444 use, = those implementations become non-compliant. So I think the real question(s)= should be: = - Do we as a WG want to force utilization of RFC5444 for the reactive proto= col, thereby losing the advantage of the existing interoperable implementat= ions? = - Or, is there a reasonable hybrid approach? To be honest, I'm much less concerned about header taxes, or how a given pa= rser scheme makes things easier in some ways, but harder in others. Regards, Stan > = > Which kind of difficulty were you most interested in? > = > I can also write about how RFC 5444 makes things easier, but > you didn't ask that question. > = > On 1/16/2013 1:46 AM, Dearlove, Christopher (UK) wrote: >> Charlie >>> Similarly, placing RFC 5444 constraints has itself made future designs = more difficult. >> In what ways? >> = > = > = > -- = > Regards, > Charlie P. > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Jan 17 02:01:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3D21F88A1 for ; Thu, 17 Jan 2013 02:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCn4YboULSTG for ; Thu, 17 Jan 2013 02:01:34 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id BF0AA21F889C for ; Thu, 17 Jan 2013 02:01:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="255728537" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jan 2013 10:01:16 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HA1Gcx000854 for ; Thu, 17 Jan 2013 10:01:16 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3594343" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 17 Jan 2013 10:01:16 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 10:01:16 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Henning Rogge Thread-Topic: [manet] Hares Technical Question 2: order of address in TLV Thread-Index: Ac3yFhOratnXSvfpSO6Gc0VvxiKSKwAEYHeAAEgtlwAAA5b0gAAJSccAABFoyoAAH4iOgAAWV5Gg Date: Thu, 17 Jan 2013 10:01:15 +0000 Message-ID: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> In-Reply-To: <50F734E9.7040701@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:01:35 -0000 I'm not sure what "positional information in TLVs" means. The discussion has been one of whether information about what an address in= a message means is carried either by where the address is (possibly which = address block, and/or in what position in an address block) or by TLVs that= attach information to the address. Neither is positional information in TL= Vs. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 16 January 2013 23:17 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Henning, On 1/16/2013 12:14 AM, Henning Rogge wrote: > > just compare RFC5444 to a piece of XML. I agree this is a very good comparison. > >> But what if a "clean protocol design" is measured by requiring >> fewer "special case" TLVs? > > If this is the case, why did we ever moved to a TLV format? Binary = > format with most things defined by their order (and not a type) are = > clearly "less overhead". People, including me, use TLVs because they are great for many purposes. Please note that there is no problem to have positional information in TLVs. > > But they can be a pain to extend later. Binary format is harder to read, that is sure. But TLVs can obviously be also in "binary format". > >> I really don't think that using the same design philosophy as has been >> used in hundreds of successful protocols should be called a "hack", >> and it certainly isn't "special" in that context. > > How many of them are TLV based formats? Given that TLVs can be (i) binary and (ii) positional, I'm not sure exactly what you are asking, and I do not know just what the percentages are. But, Mobile IP and Diameter use TLVs. > >> What about people >> who think RFC 5444 is a "hack", because there are ever more cases >> that require two-byte overhead here, two-byte overhead there, >> defining a new "hack" TLV when simple positional description would >> do? If they disappear from [manet] because their design ideas are >> labeled as "hacks", did RFC 5444 "win"? > > I am not aware of protocols leaving [manet] after RFC5444 got finalized. Well, there have been various complaints about [manet] headers being "too big". And, anyway, I was asking theoretical questions, about which I'd still like to know your opinion. > >> Moreover, as I understand it, it's not even just about RFC 5444, >> but about on the one hand conforming to someone's existing >> parser, and denigrating the word "positional". >> >>> This "positional information" is just a step backward to the packet >>> formats we had with AODV and OLSRv1. >> >> I'm not so sure which direction is forward. Anyway I hope it is >> clear that the overhead in the typical IPv6 RREQ/RREP case is >> much more than "2 bytes". > > After looking into the RREP specification in the current draft of = > AODVv2, it might be even less than 2 bytes to skip the "position = > information"... it could be zero bytes. > > The following is just an example for the RREP what we could do to get = > rid of it. > > The RREP contains two addresses, both already "tagged" with an address = > block TLV. > > We could easily take two message specific Address Block TLVs, one = > called "Route Generation Sequence number" and one called "Route = > Request Sequence Number" (the first one is similar to the Answer Set = > Number of OLSRv2). > > This would allow AODVv2 to differentiate between your originator and = > target address by looking at the TLV. This would be fine with me. It's encoding the positional information = into the AddrTLV instead of the AddrBlk. One still has to know which address is which, = so the new AddrTLV definitions would have to cover the case when both addresses = have SeqNum. We could have four AddrTLV definitions: - Single SeqNum for Originator Address - Single SeqNum for Target Address - Two SeqNums, Originator Address first - Two SeqNums, Target Address first I'm fine with this, because I see no urgency in preserving AddrTLV numbering space. However, I'm not very clear about which design is "cleaner". > > (it might also allow nodes with multiple local addresses to reply to a = > route request with more than one address, just by tagging multiple = > addresses with the corresponding TLV) Well, if we're really dealing with an exponential increase in AddrTLV = type definitions, I'm not sure about what's better. Or maybe I am missing some other way of doing the positional encoding. -- = Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Jan 17 02:06:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA53221F890E for ; Thu, 17 Jan 2013 02:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ-0qNjySlku for ; Thu, 17 Jan 2013 02:06:38 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1E21F8904 for ; Thu, 17 Jan 2013 02:06:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="301200296" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jan 2013 10:06:37 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HA6bCt022962 for ; Thu, 17 Jan 2013 10:06:37 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3819393" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 17 Jan 2013 10:06:37 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 10:06:37 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "Charles E. Perkins" Thread-Topic: [manet] Hares Technical Question 2: order of address in TLV Thread-Index: Ac3yFhOratnXSvfpSO6Gc0VvxiKSKwAEYHeAAEgtlwAAA5b0gAAJSccAABFoyoAAH4iOgAAA2BGAABWo+1A= Date: Thu, 17 Jan 2013 10:06:37 +0000 Message-ID: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:06:39 -0000 Not random, but unspecified, and permitted to be ordered for efficiency as = the message constructor chooses. Not the same. (Why can order affect efficiency? Because the most efficient way of attachi= ng TLVs is with the addresses the TLV applies to grouped together. Whether = the gain is significant depends on various details. Note that, despite usin= g multiple TLVs, this is possible in NHDP/OLSRv2. However in the simplest c= ases there is no significant gain due to order - except not having multiple= address blocks is usually a gain, unless e.g. you have two or more quite d= ifferent types of address. Even then it may not be a gain.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 16 January 2013 23:41 To: Charles E. Perkins Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > Given that TLVs can be (i) binary and (ii) positional, I'm not sure > exactly what you are asking, and I do not know just what the > percentages are. But, Mobile IP and Diameter use TLVs. > I agree with the above, but we may add (iii) random order TLVs in 5444 message, which I think prefered by Henning, AB _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Jan 17 02:15:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCE421F86B6 for ; Thu, 17 Jan 2013 02:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9hCwYNrpQ97 for ; Thu, 17 Jan 2013 02:15:08 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id BEF3221F84E0 for ; Thu, 17 Jan 2013 02:15:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="255736175" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jan 2013 10:15:07 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HAF6sq010659 for ; Thu, 17 Jan 2013 10:15:06 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3597205" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 17 Jan 2013 10:15:06 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 10:15:06 +0000 From: "Dearlove, Christopher (UK)" To: Susan Hares , "'Thomas Heide Clausen'" , "'Ulrich Herberg'" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIACZEQAgACLX3A= Date: Thu, 17 Jan 2013 10:15:05 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <003a01cdf454$d9f90be0$8deb23a0$@ndzh.com> In-Reply-To: <003a01cdf454$d9f90be0$8deb23a0$@ndzh.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:15:09 -0000 Tm8sIEkgaGF2ZSBub3QsIGFuZCBteSBwb2ludCBpcyBub3QgdGhlc2UgZXhhbXBsZXMuIE15IHBv aW50IGlzIHRoYXQgb25lIG1heSwgYXQgc29tZSBwb2ludCwgd2lzaCB0byBhZGQgYWRkaXRpb25h bCBmb3JtcyBvZiBiZWhhdmlvdXIuIFRoZXNlIGFyZSBqdXN0IHBsYXVzaWJsZSAoSSdsbCB0YWtl IFN0YW4ncyBjb21tZW50cyBhcyBhZ3JlZWluZyB0aGV5IHJlYWNoIGF0IGxlYXN0IHRoYXQgbG93 IGJhcikgZXhhbXBsZXMgb2YgdGhlIHNvcnQgb2YgdGhpbmcgdGhhdCBtaWdodCBiZSBhZGRlZC4g QnV0IGl0J3MgdGhhdCB5b3UgZG9uJ3Qga25vdyB3aGF0IHlvdSBtaWdodCBhZGQgdGhhdCBpcyB0 aGUgcG9pbnQgLSB0aGUgc3BlY2lmaWMgZXhhbXBsZXMgaW4gdGhhdCBzZW5zZSBvYnNjdXJlIHRo ZSBwb2ludC4gQSBtb3JlIGZsZXhpYmxlIGRlc2lnbiBub3cgYWxsb3dzIGVhc2llciBleHRlbnNp b24gbGF0ZXIuDQoNCkEgc3BlY2lmaWMgZXhhbXBsZSBpcyB0aGUgZXZvbHV0aW9uIG9mIHVzZSBv ZiBUTFZzIGluIGF0dGFjaGluZyB0byBhZGRyZXNzZXMgaW4gT0xTUnYyJ3MgVEMgbWVzc2FnZXMu IFlvdSBjb3VsZCBhY3R1YWxseSBtYW5hZ2Ugd2l0aG91dCBvbmUgb2YgaXRzIFRMVnMgYnkgKGlu IGVmZmVjdCkgc2F5aW5nICJhbGwgYWRkcmVzc2VzIHdpdGhvdXQgYSBUTCBhdHRhY2hlZCBhcmUg YXNzdW1lZCB0byBhY3QgYXMgaWYgdGhpcyBpbmZvcm1hdGlvbiBhcHBsaWVzIHRvIHRoYXQgYWRk cmVzcyIuIEJ1dCB0aGVuIHlvdSBjYW4ndCBhZGQgbmV3IGFkZHJlc3NlcyB3aXRoIG5ldyBwcm9w ZXJ0aWVzIC0gYW5kIHBlb3BsZSBoYXZlIHNvbWUgaWRlYXMgdGhlcmUgKG5vdCBwdWJsaXNoZWQg YXMgZmFyIGFzIEkga25vdykuIFNpbWlsYXJseSBpZiB5b3Ugc2F5ICJ0aGUgZmlyc3QgYWRkcmVz cyBoYXMgcHJvcGVydHkgLCBhbGwgb3RoZXIgYWRkcmVzc2VzIGhhdmUgcHJvcGVydHkgWSIgeW91 IGNhbid0IGhhdmUgYSBzZWNvbmQgYWRkcmVzcyB3aXRoIHByb3BlcnR5IFguIE9yIGFkZHJlc3Nl cyB3aXRoIHByb3BlcnR5IFogKGJ1dCBub3QgWSkuIE9yIGV2ZW4gbm8gYWRkcmVzc2VzIHdpdGgg cHJvcGVydHkgWCAoYnV0IHNvbWUgYWRkcmVzc2VzIHdpdGggcHJvcGVydHkgWSkuDQoNCkl0IGFs bCBkZXBlbmRzIG9uIGhvdyBleHRlbnNpYmxlIHlvdSBwbGFuIHRvIGJlLiBCdXQgdGhlcmUgYXJl IGFscmVhZHkgcGxlbnR5IG9mIHN1Z2dlc3Rpb25zIGZvciBBT0RWdjIgZXh0ZW5zaW9ucyBmbG9h dGluZyBhcm91bmQuDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lw YWwgRW5naW5lZXIsIENvbW11bmljYXRpb25zIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29y a3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRl Y2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NMKgfCAgRmF4OiArNDQg MTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIHwgaHR0cDovL3d3dy5i YWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0 ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3Nw YWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IG1hbmV0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptYW5ldC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VzYW4gSGFyZXMNClNlbnQ6IDE3IEphbnVhcnkgMjAx MyAwMTo0OQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyAnVGhvbWFzIEhlaWRlIENs YXVzZW4nOyAnVWxyaWNoIEhlcmJlcmcnDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbWFuZXRdIE5vdGlmaWNhdGlvbnMgZnJvbSB0aGUgSUVURiB0b29scyBJc3N1ZSBUcmFja2Vy DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwNCmVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQu DQpLZWVwIHRoaXMgaW4gbWluZCBpZiB5b3UgYW5zd2VyIHRoaXMgbWVzc2FnZS4NCkZvbGxvdyB0 aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzDQpmb3IgaW5z dHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQ2hy aXM6DQoNCkhhdmUgeW91IGRpc2N1c3NlZCB0aGVzZSBzY2VuYXJpb3MgYXQgYW4gSUVURiBvciBv biB0aGUgbGlzdD8gIElmIHNvLCBjYW4geW91IHBvaW50IG1lIHRvIHRoZSBJRVRGIHByZXNlbnRh dGlvbiBvciBsaXN0IGRheS4gDQpJZiBub3QsIHRoZXJlIGlzIGNvbnNpZGVyYWJsZSBjb21wbGV4 aXR5IGJlaGluZCB5b3VyIHN1Z2dlc3Rpb24uICANCg0KSGF2ZSB5b3Ugb3IgdGhlIGdyb3VwIGRv bmUgYSBsaXRlcmF0dXJlIHNlYXJjaCBvbiBhbGdvcml0aG1zIGZyb20gc2Vuc29yIGFuZCBtYW5l dCB0aGF0IGV4YW1pbmUgdGhpcz8gSSdtIGEgYml0IG91dCBvZiBkYXRlIG9uIHNlbnNvcnMgYW5k IG1vYmlsaXR5ICgyLTMgeWVhcnMgb24gREMgc3dpdGNoZXMpLCBidXQgdGhlcmUgdXNlZCB0byBi ZSBhIGxvdCBvZiBjaGFsbGVuZ2UgaW4gdGhlc2UgYWxnb3JpdGhtcy4gIA0KDQpDaGFybGllIGFu ZCBUaG9tYXMgdXNlZCB0byBlbnRlcnRhaW4gbWUgd2l0aCBpZGVhcyBhIGZldyB5ZWFycyBhZ28u IA0KDQpJJ20gbm90IHNheWluZyB0aGF0IGNvbnNpZGVyaW5nIHRoaXMgd291bGRuJ3QgYmUgZnVu IHRob3VnaCwNCg0KQ2hlZXJzLCANCg0KU3VlIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBtYW5ldC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWFuZXQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDE1LCAyMDEzIDg6MjIgQU0NClRvOiBUaG9tYXMgSGVpZGUgQ2xhdXNl bjsgVWxyaWNoIEhlcmJlcmcNCkNjOiBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5l dF0gTm90aWZpY2F0aW9ucyBmcm9tIHRoZSBJRVRGIHRvb2xzIElzc3VlIFRyYWNrZXINCg0KVG8g bXkgbWluZCwgYSBjcml0aWNhbCBxdWVzdGlvbiBpcyB3aGV0aGVyIGFuIFJSRVEgb3IgYW4gUlJF UCBtaWdodCwgYXQgc29tZSBwb2ludCwgY2FycnkgbW9yZSB0aGFuIG9uZSBhZGRyZXNzIGluIHdo YXQgaXMgdGhlIG1haW4gYWRkcmVzcyBjYXRlZ29yeS4NCg0KQ291bGQgYW4gUlJFUSBjYXJyeSBt b3JlIHRoYW4gb25lIGFkZHJlc3MgIkknbSBsb29raW5nIGZvciBBIGFuZC9vciBCIj8gKGFuZC9v ciwgYXMgSSBjb3VsZCBzZWUgZWl0aGVyIGJlaW5nIGEgcG9zc2liaWxpdHkpLg0KQ291bGQgYW4g UlJFUCBjYXJyeSBtb3JlIHRoYW4gb25lIGFkZHJlc3MgLSBlaXRoZXIgInlvdSBhc2tlZCBmb3Ig QSwgSSBhbSBBLiBJJ20gYWxzbyBCLCBDIGFuZCBEIiBvciB3aXRoIElSUkVQcyAiSSBhbHNvIHJv dXRlIHRvIEIsIEMgYW5kIEQiLg0KDQpUaGlzIHNvcnQgb2YgaW5mb3JtYXRpb24gY291bGQgYmUg ZmxhZ2dlZCB3aXRoIFRMVnMuIFBvc2l0aW9uYWxseSBpdCdzIG11Y2ggaGFyZGVyIC0gZXNwZWNp YWxseSBpZiB3ZSBtYXkgd2FudCB0byBhZGQgc3VjaCBjYXNlcyBsYXRlci4NCg0KLS0NCkNocmlz dG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBDb21tdW5pY2F0aW9u cyBHcm91cCBDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFi aWxpdHkgQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUgV2VzdCBIYW5uaW5n ZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiAr NDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQgY2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChP cGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8g Qm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMs IEdVMTQgNllVLCBVSyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5ldC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBI ZWlkZSBDbGF1c2VuDQpTZW50OiAxMSBKYW51YXJ5IDIwMTMgMTY6NTANClRvOiBVbHJpY2ggSGVy YmVyZw0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBOb3RpZmljYXRp b25zIGZyb20gdGhlIElFVEYgdG9vbHMgSXNzdWUgVHJhY2tlcg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCktlZXAgdGhpcyBpbiBtaW5kIGlm IHlvdSBhbnN3ZXIgdGhpcyBtZXNzYWdlLg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMg RW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcg c3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkluIGNvbXBsZXRlIGFncmVlbWVudCB3aXRo IFVscmljaCBoZXJlLiANCg0KQXNzb2NpYXRpbmcgc2VtYW50aWNzIHRvIG9yZGVyaW5nIG9mIFRM VnMgb3IgYWRkcmVzc2VzIGluIDU0NDQgcmVtb3ZlcyB0aGUgYWJpbGl0eSBmb3IgZ2VuZXJpYyBw YXJzZXJzIGFuZCBnZW5lcmF0b3JzLiBUaGF0IHdvdWxkIGJlIGEgdmVyeSB1bmZvcnR1bmF0ZSBk ZXNpZ24sIGdpdmVuIHRoYXQgNTQ0NCB3YXMgZGVzaWduZWQgZXhhY3RseSB0byBiZSBnZW5lcmlj Lg0KDQpUaG9tYXMNCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gMTEgamFudi4gMjAxMywgYXQg MDg6MjUsIFVscmljaCBIZXJiZXJnIDx1bHJpY2hAaGVyYmVyZy5uYW1lPiB3cm90ZToNCg0KPiBJ IGFncmVlIHdpdGggSGVubmluZy4gQSBwcm90b2NvbCB1c2luZyBSRkM1NDQ0IHNob3VsZCBub3Qg bWFuZGF0ZSBhIGNlcnRhaW4gb3JkZXIgb3IgYSBzcGxpdCBpbnRvIGFkZHJlc3MgYmxvY2tzIGZv ciB0aGUgcmVhc29ucyBIZW5uaW5nIG1lbnRpb25lZC4gVGhlIFJGQzU0NDQgcGFyc2VyL2dlbmVy YXRvciBjYW4gYmUgaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sIHRoYXQgdXNlcyBpdCAoaW4g bXkgTE9BRG5nIGNvZGUgdGhhdCdzIHRoZSBjYXNlKSwgYW5kIHVzZWQgYnkgc2V2ZXJhbCBwcm90 b2NvbCBpbXBsZW1lbnRhdGlvbnMgYW5kIGV4dGVuc2lvbnMgY29uY3VycmVudGx5LiBUaGUgcHJv dG9jb2xzIGFuZCBleHRlbnNpb25zIG1heSBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0aGUgaW5mb3Jt YXRpb24gYWJvdXQgcG9zaXRpb25zIG9yIHNwbGl0IGludG8gYWRkcmVzcyBibG9ja3MuDQo+IA0K PiBJbiBMT0FEbmcsIG5vIHN1Y2gga25vd2xlZGdlIGlzIHJlcXVpcmVkLg0KPiANCj4gUmVnYXJk cw0KPiBVbHJpY2gNCj4gDQo+IE9uIEphbiAxMCwgMjAxMywgYXQgMjM6MDMsIEhlbm5pbmcgUm9n Z2UgPGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlPiB3cm90ZToNCj4gDQo+PiBPbiAw MS8xMC8yMDEzIDA4OjQyIEFNLCBDaGFybGVzIEUuIFBlcmtpbnMgd3JvdGU6DQo+Pj4gSGVsbG8g SGVubmluZywNCj4+PiANCj4+PiBJJ2xsIHB1dCB0aGUgaXNzdWUgb24gdGhlIElzc3VlIFRyYWNr ZXIgdG9tb3Jyb3cuDQo+Pj4gDQo+Pj4gSG93ZXZlciwgdGhlcmUgaGF2ZSBiZWVuIG1hbnkgcHJv dG9jb2xzIHVzaW5nIHBvc2l0aW9uYWwgaW5mb3JtYXRpb24gDQo+Pj4gZm9yIGxpc3RzIChvZiBh ZGRyZXNzZXMsIGV0Yykgd2l0aG91dCBpbXBhaXJtZW50IG9mIGV4dGVuc2liaWxpdHkuDQo+Pj4g VGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgd2hlbiBleHRlbnNpb25zIGdvIGF0IHRoZSBlbmQuICBE byB5b3UgaGF2ZSANCj4+PiBhbnkgcGFydGljdWxhciBleGFtcGxlIGluIG1pbmQgd2hlcmUgUkZD IDU0NDQgc29tZWhvdyBjcmVhdGVzIGEgDQo+Pj4gcHJvYmxlbSB3aXRoIHRoaXM/DQo+PiANCj4+ IFdpdGggTkhEUCwgT0xTUnYyIGFuZCBMT0FEbmcgaXRzIHRyaXZpYWwgdG8gZXh0ZW5kIHRoZSBw cm90b2NvbCBiZWNhdXNlIEkgY2FuIGp1c3QgYWRkIHdoYXRldmVyIEkgd2FudCB0byB0aGUgcHJv dG9jb2wgbWVzc2FnZSwgYXMgbG9uZyBhcyBJIHVzZSBuZXcgVExWcy4NCj4+IA0KPj4gTmV3IGFk ZHJlc3Nlcz8gTm8gcHJvYmxlbSwgcmVnYXJkbGVzcyBvbiB0aGUgcG9zaXRpb24uDQo+PiANCj4+ IE5ldyBUTFZzIG9uIGV4aXN0aW5nIGFkZHJlc3Nlcz8gTm8gcHJvYmxlbSB0b28uDQo+PiANCj4+ IFdoeSB1c2UgYSBwdXJlIFRMViBmb3JtYXQgaWYgd2UgcHV0IHBhcnRzIG9mIHRoZSBpbmZvcm1h dGlvbiBpbnRvIHRoZSBvcmRlciBhbmQgc3RydWN0dXJlIG9mIHRoZSBmb3JtYXQgYW5kIGRvIE5P VCB1c2UgVExWcyBmb3IgaXQ/DQo+PiANCj4+IFRoZSByZXN0cmljdGlvbiBvZiB0aGUgb3JkZXIg b2YgYWRkcmVzc2VzIGFuZCB0aGUgbWFuZGF0b3J5IHNwbGl0IGludG8gbXVsdGlwbGUgYWRkcmVz cyBibG9ja3MgaXMgYWxzbyBhIHByb2JsZW0gZm9yIGFkZHJlc3MgY29tcHJlc3Npb24uIFRoZSBv cmRlciBhbmQgc3BsaXQgaGF2ZSBhIGh1Z2UgaW5mbHVlbmNlIG9uIHRoZSBjb21wcmVzc2lvbiBl ZmZpY2llbmN5LCBkZW1hbmRpbmcgYSBzcGVjaWZpYyBzcGxpdC9vcmRlciB3aWxsIG1ha2UgQU9E VnYyIG1lc3NhZ2VzIGxhcmdlciBpbiBzb21lIGNhc2VzLg0KPj4gDQo+PiBIZW5uaW5nIFJvZ2dl DQo+PiANCj4+IA0KPj4gLS0NCj4+IERpcGxvbS1JbmZvcm1hdGlrZXIgSGVubmluZyBSb2dnZSAs IEZyYXVuaG9mZXItSW5zdGl0dXQgZsO8ciANCj4+IEtvbW11bmlrYXRpb24sIEluZm9ybWF0aW9u c3ZlcmFyYmVpdHVuZyB1bmQgRXJnb25vbWllIEZLSUUgDQo+PiBLb21tdW5pa2F0aW9uc3N5c3Rl bWUgKEtPTSkgRnJhdW5ob2ZlciBTdHJhw59lIDIwLCA1MzM0MyBXYWNodGJlcmcsIA0KPj4gR2Vy bWFueQ0KPj4gVGVsZWZvbiArNDkgMjI4IDk0MzUtOTYxLCAgIEZheCArNDkgMjI4IDk0MzUgNjg1 DQo+PiBtYWlsdG86aGVubmluZy5yb2dnZUBma2llLmZyYXVuaG9mZXIuZGUgaHR0cDovL3d3dy5m a2llLmZyYXVuaG9mZXIuZGUNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXRAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQgbWFp bGluZyBsaXN0DQo+IG1hbmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQg bm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yIGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBs aXN0DQptYW5ldEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVs ZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxk IG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRp c3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From Chris.Dearlove@baesystems.com Thu Jan 17 02:20:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4098821F8880 for ; Thu, 17 Jan 2013 02:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzdfGx-d-tkK for ; Thu, 17 Jan 2013 02:20:35 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA521F886C for ; Thu, 17 Jan 2013 02:20:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="301207493" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jan 2013 10:20:28 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HAKRRt009488 for ; Thu, 17 Jan 2013 10:20:28 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3822127" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 17 Jan 2013 10:20:27 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 10:20:27 +0000 From: "Dearlove, Christopher (UK)" To: Susan Hares , "'Henning Rogge'" Thread-Topic: [manet] Hares Technical Issue 4 - GTSM Thread-Index: Ac3yG1ooffsJJST5TemjEv3rrPLmmQADjhmAAA5gSoAAAFw9AAAwPTZgAEvlwIAAEZ+3kA== Date: Thu, 17 Jan 2013 10:20:27 +0000 Message-ID: References: <004101cdf21b$60689d80$2139d880$@ndzh.com> <50F3B4FF.20408@fkie.fraunhofer.de> <012801cdf263$14855960$3d900c20$@ndzh.com> <50F417E4.8070304@fkie.fraunhofer.de> <003c01cdf455$114403c0$33cc0b40$@ndzh.com> In-Reply-To: <003c01cdf455$114403c0$33cc0b40$@ndzh.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Issue 4 - GTSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:20:36 -0000 This is not subject to confirmation in the sense of I need to verify which = RFC says what, but rather a view of best presentation. My view is that this= belongs as a development of 5498, which is where it is mandated what to do= is, rather than 5444. (Actually, I don't think the existing split between = the two is right, but that's water under the bridge.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= usan Hares Sent: 17 January 2013 01:51 To: Dearlove, Christopher (UK); 'Henning Rogge' Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Chris: Could you verify it today? I'm writing up some comments for KARP for Stewart Bryant, and I'd like to include it in my email. Thanks, Sue = -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] = Sent: Tuesday, January 15, 2013 8:39 AM To: Henning Rogge; Susan Hares Cc: manet@ietf.org Subject: RE: [manet] Hares Technical Issue 4 - GTSM I think perhaps the correct place is actually 5498 rather than 5444. (5498 mandates - on the manet port/protocol - that which 5444 provides as a proposed usage.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.co= m | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 14 January 2013 14:36 To: Susan Hares Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Issue 4 - GTSM On 01/14/2013 03:26 PM, Susan Hares wrote: > Henning: > > Again, thank you for aiding my understanding. > > Do I understand from this message that RFC5444 should be the protocol = > running GTSM? Yes, I think GTSM is a security consideration (and option) for RFC5444. So AODVv2 could suggest using it for RFC5444, but I don't think its the place to mandate its usage. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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://www.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. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Jan 17 02:27:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1375221F8903 for ; Thu, 17 Jan 2013 02:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z76+9p1zBpe for ; Thu, 17 Jan 2013 02:27:31 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id CAEC921F8901 for ; Thu, 17 Jan 2013 02:27:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="301211230" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jan 2013 10:27:30 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HART7t020141 for ; Thu, 17 Jan 2013 10:27:29 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3823554" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 17 Jan 2013 10:27:29 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 10:27:29 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAANuoAgAAsxwCAAAylgIAA5oQQgACHUACAAATngIAAEOsAgABDCoCAAIp/AIAAMdVQ Date: Thu, 17 Jan 2013 10:27:28 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> <50F7A6D2.8010008@fkie.fraunhofer.de> In-Reply-To: <50F7A6D2.8010008@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:27:32 -0000 I will say that OLSRv2 split into five documents (not counting metrics rati= onale, MIB, or future security documents). In my ideal world in which I (an= d my co-suthors) had unlimited time, I would have had two more, one of whic= h would have been a separation between a message specification in terms of = addresses and attributes, and a mapping of the latter to 5444. (The other, = just for interest, is that OLSRv2's processing and forwarding engine is pot= entially reusable outside OLSRv2.) Whether XML is the best intermediate for= m could be debated - and it might be important to understand whether the XM= L is being used as a presentational approach, or really intended for use. I= t has drawbacks in both cases, as well as advantages. The major dangers I s= ee are people thinking you must use XML in your implementation - really you= shouldn't even hint that - and taht the XML might itself obscure matters i= n that intermediate step. Arguably XML isn't that intermediate step, but an= other thing that the abstract "addresses and attributes" could be coded as. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 17 January 2013 07:23 To: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker On 01/17/2013 12:07 AM, Abdussalam Baryun wrote: > Hi Henning, > > I am not sure I understand the example you made, could you give a > suggestion of better design of RREQ and RREP for AODVv2 so we can > reasonably go through the protocol functionality. > > Giving general exmples will not produce protocols for our WG, even the > RFC5444 is flexibile but let us go through the reactive protocol > messaging and its reflection on the function, not just giving > interesting things outside the function, as compressing, I was talking about a potential new Draft for this working group which = defines a transparent compression/decompression scheme for RFC5444 messages. I think this is "in scope" of this WG. Henning Rogge -- = Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** ******************************************************************** 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. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Jan 17 02:31:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085BE21F8903 for ; Thu, 17 Jan 2013 02:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+huuwvfIYzF for ; Thu, 17 Jan 2013 02:31:51 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id BB52A21F86CA for ; Thu, 17 Jan 2013 02:31:50 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TvmlC-0000QZ-4D; Thu, 17 Jan 2013 11:31:50 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TvmlC-0001oL-1W; Thu, 17 Jan 2013 11:31:50 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 17 Jan 2013 11:31:49 +0100 Message-ID: <50F7D314.5020603@fkie.fraunhofer.de> Date: Thu, 17 Jan 2013 11:31:48 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> <50F7A6D2.8010008@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040308060803070406000702" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16510/Thu Jan 17 06:40:51 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a8bb361c08068357dcb389a69381f4e8 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:31:53 -0000 --------------ms040308060803070406000702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/17/2013 11:27 AM, Dearlove, Christopher (UK) wrote: > I will say that OLSRv2 split into five documents (not counting > metrics rationale, MIB, or future security documents). In my ideal > world in which I (and my co-suthors) had unlimited time, I would have > had two more, one of which would have been a separation between a > message specification in terms of addresses and attributes, and a > mapping of the latter to 5444. (The other, just for interest, is that > OLSRv2's processing and forwarding engine is potentially reusable > outside OLSRv2.) Whether XML is the best intermediate form could be > debated - and it might be important to understand whether the XML is > being used as a presentational approach, or really intended for use. > It has drawbacks in both cases, as well as advantages. The major > dangers I see are people thinking you must use XML in your > implementation - really you shouldn't even hint that - and taht the > XML might itself obscure matters in that intermediate step. Arguably > XML isn't that intermediate step, but another thing that the abstract > "addresses and attributes" could be coded as. Just to make sure you understand me correctly... I do NOT want to use XML anywhere in the context of RFC5444. I want to develop something similar to XML-schema based compression for=20 RFC5444, because I think the same principle could be used for MANET=20 protocols on top of RFC5444. (its also similar to the IETF Robust Header Compression standard for IP=20 and transport level protocols) The goal is a transparent compressor, which takes RFC5444 binary packets = as input and outputs a compressed packet based on a schema=20 representation of the protocols in use. On the receiver end there will be a transparent decompresser, which=20 reconstructs the original RFC5444 packets based on the same schema as=20 the compressor on the other end. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040308060803070406000702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTcxMDMxNDhaMCMGCSqGSIb3DQEJBDEWBBTKzCXAWyfcJwvC0Flo6V0GxqFdWDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAoszjyAJpstVKlQzl/ipX94m3506lPOxXJ4HlMr9jzBis qZCB0SkIhS2tSjbVsODkvDihU2UkvaFh/51A7GxpVtmcOeDXmdije+aKC3NgpU5TWQxikugB 4r3YPKySbNLfbBhk7JabprGqdnHmbaTeAbYY+Mc+hV1y0T5c9AdIBVu/1LlwIotAnVxGHGU6 12dZN6LWyNLsgrBaaYSinzDdpxaXHgrUJ2rCiinXLXRn9VOHCg1YW9E0LpudOZAmPW+c7xod aNLUi3C5An664s1K47fYG/6+3pkITxuclQcfUpqHcFP9KQtzqGBGeS9BnR/fd1PrhWJAnJjd bX+X+3juqAAAAAAAAA== --------------ms040308060803070406000702-- From yuichi.igarashi.hb@hitachi.com Thu Jan 17 03:18:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E751521F8B29 for ; Thu, 17 Jan 2013 03:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0HazPYpooBQ for ; Thu, 17 Jan 2013 03:18:26 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id CF3E521F8B6C for ; Thu, 17 Jan 2013 03:18:25 -0800 (PST) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id A00C637AC2 for ; Thu, 17 Jan 2013 20:18:24 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id r0HBIOME031587; Thu, 17 Jan 2013 20:18:24 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r0HBINmk012020 for ; Thu, 17 Jan 2013 20:18:24 +0900 Received: from hsdlmain.sdl.hitachi.co.jp (unknown [133.144.14.194]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 725AB490051 for ; Thu, 17 Jan 2013 20:18:23 +0900 (JST) Received: from hsdlvgate2.sdl.hitachi.co.jp by hsdlmain.sdl.hitachi.co.jp (8.13.8/3.7W11021512) id r0HBINmf007648; Thu, 17 Jan 2013 20:18:23 +0900 X-AuditID: 85900ec0-d4077b900000152f-a5-50f7ddff0482 Received: from sdl99w.sdl.hitachi.co.jp (sdl99w.sdl.hitachi.co.jp [133.144.14.250]) by hsdlvgate2.sdl.hitachi.co.jp (Symantec Mail Security) with ESMTP id 225CB236561; Thu, 17 Jan 2013 20:18:23 +0900 (JST) Received: from maila.sdl.hitachi.co.jp (sdl99a.sdl.hitachi.co.jp [133.144.14.196]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id D8C6653C1F5; Thu, 17 Jan 2013 20:19:12 +0900 (JST) Received: from [10.198.210.67] (unknown [10.198.210.67]) by maila.sdl.hitachi.co.jp (Postfix) with ESMTP id 14210495B84; Thu, 17 Jan 2013 20:18:23 +0900 (JST) Message-ID: <50F7DDFD.8010100@hitachi.com> Date: Thu, 17 Jan 2013 20:18:21 +0900 From: Yuichi IGARASHI User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 Cc: "manet@ietf.org" References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> In-Reply-To: <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 11:18:27 -0000 Hi Abdussalam, We have two different independent implementations. Even in my company, we had no director among implementors, because our main purpose was to confirm the interoperability of LOADng spec. Best regards, Yuichi (2013/01/17 18:48), Thomas Heide Clausen wrote: > > > Sent from my iPad > > On 17 janv. 2013, at 09:52, Abdussalam Baryun wrote: > >> Hi Thomas, >> >> sorry for my understandning, but as you may know my English is not the >> first language and I am new in the IETF vocabulary, I like to learn > > Nor is English my first language ;) > >> On 1/17/13, Thomas Heide Clausen wrote: >>> Abdussalam, >>> >>> This is really incredible; did you actually _read_ the Interoperability >>> report? Please do so, before jumping to assumptions. >> >> yes read quickly but not assuming what I understood it was realy what >> I felt, and just stated the fact of my first reading. I agree that I >> need to improve :) > > I recommend that, if you want to comment on a document, you read it carefully. It's not efficient to have to repeat things, which are already well documented and in detail. > >>> For each interoperability event, there is a section "Participating >>> Implementations". Here's an example, snipped from the draft from the _first_ >>> interop test (when there were just 3 implementations - the latter tests had >>> 4). It is explicitly mentioned that in that test, there's one Java >>> implementation, one C implementation for an embedded platform and one C++ >>> implementation for MacOS. >> >> So my understanding from your reply that the test were done within 4 >> different languages and environments. What about the implementor, were >> they in contact and followed a same director/advisor, were there an >> independance in implementing the understanding of specification. I >> think not documented so far in my reading. > > As the implementations were done by different (and, in some cases, competing) corporate entities/companies, I would be quite surprised if the different engineers had the same "director/advisor". > > This is also documented in the report (companies, and even people). > > > Thomas > >> I may be wrong, please advise, >> >> AB > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Hitachi, Ltd., Yokohama Research Laboratory IGARASHI Yuichi Mail： yuichi.igarashi.hb@hitachi.com Tel ： +81-(0)45-860-3083 FAX ： +81-(0)45-860-1673 From Chris.Dearlove@baesystems.com Thu Jan 17 05:11:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC93321F869B for ; Thu, 17 Jan 2013 05:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-apLJGm7Tww for ; Thu, 17 Jan 2013 05:11:45 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B02B021F861A for ; Thu, 17 Jan 2013 05:11:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="301293784" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jan 2013 13:11:43 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HDBg0t023878 for ; Thu, 17 Jan 2013 13:11:42 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6957"; a="3854587" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 17 Jan 2013 13:11:42 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 13:11:42 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN7rr9bJtZ+zulZEq9CpdJ9dTPlZhCLIwAgAACIACAAYdFgIAABkqAgACdtoCABg4HIIAANuoAgAAsxwCAAAylgIAA5oQQgACHUACAAATngIAAEOsAgABDCoCAAIp/AIAAMdVQgAAC7QCAACyQcA== Date: Thu, 17 Jan 2013 13:11:42 +0000 Message-ID: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> <50F7A6D2.8010008@fkie.fraunhofer.de> <50F7D314.5020603@fkie.fraunhofer.de> In-Reply-To: <50F7D314.5020603@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 13:11:46 -0000 OK, that's something different than I read you as suggesting. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 17 January 2013 10:32 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker On 01/17/2013 11:27 AM, Dearlove, Christopher (UK) wrote: > I will say that OLSRv2 split into five documents (not counting > metrics rationale, MIB, or future security documents). In my ideal > world in which I (and my co-suthors) had unlimited time, I would have > had two more, one of which would have been a separation between a > message specification in terms of addresses and attributes, and a > mapping of the latter to 5444. (The other, just for interest, is that > OLSRv2's processing and forwarding engine is potentially reusable > outside OLSRv2.) Whether XML is the best intermediate form could be > debated - and it might be important to understand whether the XML is > being used as a presentational approach, or really intended for use. > It has drawbacks in both cases, as well as advantages. The major > dangers I see are people thinking you must use XML in your > implementation - really you shouldn't even hint that - and taht the > XML might itself obscure matters in that intermediate step. Arguably > XML isn't that intermediate step, but another thing that the abstract > "addresses and attributes" could be coded as. Just to make sure you understand me correctly... I do NOT want to use XML anywhere in the context of RFC5444. I want to develop something similar to XML-schema based compression for=20 RFC5444, because I think the same principle could be used for MANET=20 protocols on top of RFC5444. (its also similar to the IETF Robust Header Compression standard for IP=20 and transport level protocols) The goal is a transparent compressor, which takes RFC5444 binary packets=20 as input and outputs a compressed packet based on a schema=20 representation of the protocols in use. On the receiver end there will be a transparent decompresser, which=20 reconstructs the original RFC5444 packets based on the same schema as=20 the compressor on the other end. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From charliep@computer.org Thu Jan 17 06:47:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DE421F8640 for ; Thu, 17 Jan 2013 06:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTZgiM+HIiwh for ; Thu, 17 Jan 2013 06:47:01 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 2431C21F863C for ; Thu, 17 Jan 2013 06:47:01 -0800 (PST) Received: from [206.191.100.2] (helo=[172.17.137.69]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tvqk8-0000AU-CN; Thu, 17 Jan 2013 09:47:00 -0500 Message-ID: <50F80EDE.5060403@computer.org> Date: Thu, 17 Jan 2013 06:46:54 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Henning Rogge References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> In-Reply-To: <50F7A31F.8070309@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad863c9aca74d4098223ce18e67892f076fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 206.191.100.2 Cc: manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:47:01 -0000 Hello Henning, On 1/16/2013 11:07 PM, Henning Rogge wrote: > On 01/17/2013 12:16 AM, Charles E. Perkins wrote: >> People, including me, use TLVs because they are great for >> many purposes. Please note that there is no problem to >> have positional information in TLVs. > > To come back to XML, you would not do positional informations in > XML... and I think you shouldn't do this in RFC5444 either. The logical conclusion of this argument, is to simply do XML. It's a matter of how much overhead, for what gain. > >> Well, there have been various complaints about [manet] headers >> being "too big". And, anyway, I was asking theoretical questions, about >> which I'd still like to know your opinion. ... > > >>> After looking into the RREP specification in the current draft of >>> AODVv2, it might be even less than 2 bytes to skip the "position >>> information"... it could be zero bytes. Your solution below is definitely not zero bytes overhead. >>> >>> The following is just an example for the RREP what we could do to get >>> rid of it. >>> >>> The RREP contains two addresses, both already "tagged" with an address >>> block TLV. >>> >>> We could easily take two message specific Address Block TLVs, one >>> called "Route Generation Sequence number" and one called "Route >>> Request Sequence Number" (the first one is similar to the Answer Set >>> Number of OLSRv2). >>> >>> This would allow AODVv2 to differentiate between your originator and >>> target address by looking at the TLV. >> > No, it does not...i propose to use a DIFFERENT TLV for the "route > generation sequence number" and for the "route request sequence number". > > By this it encodes the same information without the need of any > special position. > > The implementation can easily decide for each address if its an > originator, a target or something else (to ignore the address) just by > looking WHICH TLV is attached to the address. I'll map this out in detail and make the comparison. I'm fine with a solution that can be encoded without too much overhead, and as mentioned before I am not too concerned about chewing up TLV type space. -- Regards, Charlie P. From sratliff@cisco.com Thu Jan 17 06:57:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2F721F85AE for ; Thu, 17 Jan 2013 06:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62AirVjAg1Hu for ; Thu, 17 Jan 2013 06:57:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6721F85AB for ; Thu, 17 Jan 2013 06:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1358434676; x=1359644276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4q6r3GRUxqLJk9RxWwPdcOl40kR8c0yg+rIpeQPQI3U=; b=iNoZMtZyunJjwd1c189NOv3BNcTJ5Vem1EaiW97kMHAcDB4esBVwYMAB KIpu7PfptFb9ELPpagPqVyl26VpFckP9uvsKWntnuQmZ9QeL6KNqL4KVP qri+BXkvArYmqJSaG+TWuAs8DzmjUAh0L2vsARkhIQuUFK69XpC42D5qJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACcQ+FCtJXHA/2dsb2JhbABEviQWc4IeAQEBAwEBAQFrCxACAQgYCiQnCyUCBA4FCIgLBgy6KwSQV2EDplWCdYIk X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="163839238" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jan 2013 14:57:55 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0HEvt35006444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 14:57:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 08:57:55 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] Stability versus gateway specification Thread-Index: AQHN8ultiViScht9O0udWwnMyyy8CZhKVcIAgAAG6oCAAAL6AIACwIWAgAAH2ICAANzMgA== Date: Thu, 17 Jan 2013 14:57:54 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> In-Reply-To: <50F75839.5000104@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.214] Content-Type: text/plain; charset="Windows-1252" Content-ID: <44F88F4981018B4E9D393A094DC01148@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:57:57 -0000 On Jan 16, 2013, at 8:47 PM, Charles E. Perkins wrote: >=20 > Hello Sue, >=20 > I am fine with your three points. >=20 > The WG manet protocols are applicable to networks for which > the nodes populating the networks are known to have unique > addresses. So it would probably break the WG specifications > to have non-unique net-10 addresses. >=20 > I think that it probably makes sense to improve the > "Applicability Statement" to restrict AODVv2 for deployment > only in networks where the nodes have unique IP addresses. OK, I'm going to admit to writing this response without reading the "down t= hread" emails (man, we've gotten chatty recently)=85=20 I'm going to be in complete DISagreement about "writing the problem away" w= ith regard to the above applicability statement. As the thread to this poin= t has shown, address overlap is going to occur. It's extremely prevalent in= the networks I work on. Employing a lot of poly-syllabic geek-speak that w= ill parse down to "Don't do that." doesn't help users very much. To be hone= st, I don't have the answer, but I think this topic deserves some more disc= ussion. I would suggest that we take Sue's point #3 and amend slightly to "= We'll work on this some now and see if there's a reasonable approach. If no= t, it may be something we defer, as it brings up thoughts of the working gr= oup whose name shall not be mentioned."=85 ;-) Regards, Stan >=20 > Regards, > Charlie P. >=20 > On 1/16/2013 5:19 PM, Susan Hares wrote: >> Henning and Charlie: >>=20 >> Sorry for delay in responding.... >>=20 >> The 10.0.0.0/8 example will occur in the wild. People will pull out thei= r >> manet router with factory defaults. >>=20 >> I have seen routing policy that forbids 10.0.0.0/8 in a network (Henning= 's >> example). >> I have also seen Charlie's example where the people blocked each other. >>=20 >> I'm sorry to be dense here. Your two behaviors simply restate the basics= of >> routing and policy. >> If you allow external route or static route insertion, these are possibl= e. >>=20 >> I thought the answer you both gave me was: >>=20 >> 1) this is insertion of routes into reactive protools is useful but hard= , >> 2) current manet protocols will go on without prefix insertion, >> 3) We'll work next on as a specific topic. >>=20 >> I look forward to working on the route insertion at the right time with = both >> of you. >>=20 >>=20 >> Sue >>=20 >>=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Jan 17 07:03:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516F21F84BC for ; Thu, 17 Jan 2013 07:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqygKxIGBD1V for ; Thu, 17 Jan 2013 07:03:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 315DD21F848B for ; Thu, 17 Jan 2013 07:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1279; q=dns/txt; s=iport; t=1358434984; x=1359644584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=peICjUTqPgKo7HBavy9WMUD6t0CwKsOmVAVcJtLlnNQ=; b=mrHjnfz/I3S7IJ6YZ0raWh+1U4Cre0SoG7QaxMBty0pVcoqwWJVWHTax utqwCxorc7iHg8bjd13Q4DdguTJef6DVAzCxoZwpwE/dkyoDc6AwDnro2 1RgDb/1yV2vHXkgcbHVUDTqXeiShPftC9V81UN3zJOtdM3uVqWbegq07j E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANcR+FCtJXG+/2dsb2JhbABEukWDXxZzgh4BAQEDAXkFCwIBCBgKJDIlAgQODYgLBrpBkFdhA4gsii2TfIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="163627971" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jan 2013 15:03:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0HF33sd015934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 15:03:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 09:03:03 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Hares Technical Question 2: order of address in TLV Thread-Index: AQHN80hLatnXSvfpSO6Gc0VvxiKSK5hLK1SAgABKTgCAAItGgIAA/EWAgACDYYCAAIT0AA== Date: Thu, 17 Jan 2013 15:03:02 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> In-Reply-To: <50F7A31F.8070309@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.214] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 15:03:05 -0000 On Jan 17, 2013, at 2:07 AM, Henning Rogge wrote: > On 01/17/2013 12:16 AM, Charles E. Perkins wrote: >> People, including me, use TLVs because they are great for >> many purposes. Please note that there is no problem to >> have positional information in TLVs. >=20 > To come back to XML, you would not do positional informations in XML... a= nd I think you shouldn't do this in RFC5444 either. +1 I have no specific scenario in mind, but creating positional requirements c= ould be "kiss of death" for routers, especially if the processing leads to = data moves inside a packet. By that, I mean if you have a scenario where yo= u have a sound, good packet partially built, *then* come up on a situation = where you have to reorganize the packet to add an additional, position-depe= ndent TLV, you've just taken a huge performance hit in order to shuffle the= data around. It's much better to just slap another TLV onto the end of the= packet, and keep on moving.=20 Regards, Stan >=20 >>> How many of them are TLV based formats? >>=20 >> Given that TLVs can be (i) binary and (ii) positional, I'm not sure >> exactly what you are asking, and I do not know just what the >> percentages are. But, Mobile IP and Diameter use TLVs. [snip]= From teco@inf-net.nl Thu Jan 17 08:17:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C321F84F1 for ; Thu, 17 Jan 2013 08:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoPD4-kPE3yd for ; Thu, 17 Jan 2013 08:17:54 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id 224ED21F84F0 for ; Thu, 17 Jan 2013 08:17:53 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id em20so2866693lab.28 for ; Thu, 17 Jan 2013 08:17:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=RJXgyKeW0emyzAcz+ivN6VYHTWTPo4+jYouSxqZ3l9U=; b=Fsgd3BPEzAPzqyLvJk9n5GL9jfikEkeruczZDQO/tpDgaNVZcxFXV2r0pGbwZ8rWkr pok//62NtEc/3zgAry+Sjzrq2br8Q6dF6KgNEEghQTCshjQoQk/jJxCOnrt83q5ioaVW noI1r4kb4jSjSU74LDZoXKSWE0mEv61pfoWhHvwybczC5+rY7GKXAy6F9frO71qy2Ibh 2ytkbJId7EPzKkte+s/5ezwOoC4Uhqlbs4Iorva8X3jTmzy60tIHcSwuuyV84FpHMTh8 LD1gsnn78u0S/DnPU0XxNkAEsmpMrxL+rShKKrmpqB+O6iOJGHkWwWjljm1mFTbNZixF ZJ6Q== X-Received: by 10.112.38.66 with SMTP id e2mr2388349lbk.90.1358439472335; Thu, 17 Jan 2013 08:17:52 -0800 (PST) Received: from [10.87.43.224] ([80.187.201.33]) by mx.google.com with ESMTPS id s9sm1023101lbc.12.2013.01.17.08.17.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 08:17:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> Date: Thu, 17 Jan 2013 17:17:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkWdF5Ok6WmrzdsW66VaTztY9SJ+9RjwWMvzn/WQeiXZ+X0jyiBeNG9NsvlWvK3QvwqjYoJ Cc: "" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:17:55 -0000 +/- 1 This positional vs. TLV discussion is getting somewhat black and white. = Looking out of my window, I see a grey world. Ahh, Dutch foggy = weather... Encode each and every bit in a TLV, where such bits are in a group, = isn't that smart. An array of bits makes lots of sense. Positional = encoded info is in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 = bits and the exponent & mantissa fields). So I can't see why it is bad to use a TLV "payload" value with multiple = fields. Could be multiple addresses. Yes, address block TLV is another = tool that could be used. It is up to the protocol designers to make = smart decisions. Teco Op 17 jan. 2013, om 16:03 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jan 17, 2013, at 2:07 AM, Henning Rogge wrote: >=20 >> On 01/17/2013 12:16 AM, Charles E. Perkins wrote: >>> People, including me, use TLVs because they are great for >>> many purposes. Please note that there is no problem to >>> have positional information in TLVs. >>=20 >> To come back to XML, you would not do positional informations in = XML... and I think you shouldn't do this in RFC5444 either. >=20 > +1 >=20 > I have no specific scenario in mind, but creating positional = requirements could be "kiss of death" for routers, especially if the = processing leads to data moves inside a packet. By that, I mean if you = have a scenario where you have a sound, good packet partially built, = *then* come up on a situation where you have to reorganize the packet to = add an additional, position-dependent TLV, you've just taken a huge = performance hit in order to shuffle the data around. It's much better to = just slap another TLV onto the end of the packet, and keep on moving.=20 >=20 > Regards, > Stan >=20 >>=20 >>>> How many of them are TLV based formats? >>>=20 >>> Given that TLVs can be (i) binary and (ii) positional, I'm not sure >>> exactly what you are asking, and I do not know just what the >>> percentages are. But, Mobile IP and Diameter use TLVs. > [snip] > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Jan 17 08:58:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8415E21F866D for ; Thu, 17 Jan 2013 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OnBl9G5KAc8 for ; Thu, 17 Jan 2013 08:58:49 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 70DF321F878F for ; Thu, 17 Jan 2013 08:58:49 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id p16so2716091vcq.39 for ; Thu, 17 Jan 2013 08:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=42AGNIK7cJwosehHuy94NiuMee8O7aPQUFNWJk3A+bk=; b=NEhjeZ4fgHv+L7Pe9n6IAS5buU6C5AP8zhjFPAhewPAaqhXmccNsET5pc1yUADJQi6 kkyt1iQiHaU1W1L4Q21NnrVksMTdzQQUt0XNfqhDoWUuyjOrieGHrqL8CEOx45hlaVi7 oAzVgOb3T3Url2zmHF81C6qjFTxcsm82W/MLk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=42AGNIK7cJwosehHuy94NiuMee8O7aPQUFNWJk3A+bk=; b=puFUaJeKPnDr7F/y7AMOIGHyDP4PaiWputjd6SbDhsi/FuDB0A6IN4k6L0wN3+wZxv eL0TmhCMYKxj0Emvxiy0TDyOpBfkNH24I3aCh6q93ygL+crWC+OzhsViBBobRudh/emn oAMIN0gqOnbb0LXaX9jt0ZAHCLeHPf0mcpRs/80LXoLxr5N8pBOpzFS76LvGss3ylhrK W3NeHQ4T1jgk/YZ6gbF43iKqYv5UUOqUv6QZlPruWzvXhZKV41mIsYkxXeyrkGCJhkTs sbZpQJm3y4rviNIP5QW1uXp6aGGvaj2vGVG1dRDCZrbu/QLEx0iO2Wr8Nsk3+jfb8JaB 6Dtw== MIME-Version: 1.0 X-Received: by 10.220.221.78 with SMTP id ib14mr774200vcb.51.1358441928445; Thu, 17 Jan 2013 08:58:48 -0800 (PST) Received: by 10.220.5.16 with HTTP; Thu, 17 Jan 2013 08:58:48 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> Date: Thu, 17 Jan 2013 08:58:48 -0800 Message-ID: From: Ulrich Herberg To: Teco Boot Content-Type: multipart/alternative; boundary=14dae9cfcba697ceee04d37ee8af X-Gm-Message-State: ALoCoQlGwkstyYguOUNAmWq/t78tQJvHxhhDkxrKpV2JezIcZgFFTYcMdfdqD6F2j79bMie/JGJl Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:58:50 -0000 --14dae9cfcba697ceee04d37ee8af Content-Type: text/plain; charset=ISO-8859-1 Teco, On Thu, Jan 17, 2013 at 8:17 AM, Teco Boot wrote: > +/- 1 > > This positional vs. TLV discussion is getting somewhat black and white. > Looking out of my window, I see a grey world. Ahh, Dutch foggy weather... > I can't say the same about the weather here in California ;-) > > Encode each and every bit in a TLV, where such bits are in a group, isn't > that smart. An array of bits makes lots of sense. Positional encoded info > is in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 bits and the > exponent & mantissa fields). > I think the discussion was about a fixed position of addresses that are associated with some meaning (e.g., 1st position in the 1st address block means destination address); not about representation of a TLV value (e.g., how to interpret the value of the LINK_METRIC TLV). > > So I can't see why it is bad to use a TLV "payload" value with multiple > fields. Could be multiple addresses. That is already supported with TLVs, both by using start- and stop-index as well as multi-value TLVs, and does not require positional assumptions of addresses in RFC5444 messages. Best regards Ulrich > Yes, address block TLV is another tool that could be used. It is up to the > protocol designers to make smart decisions. > > Teco > > > Op 17 jan. 2013, om 16:03 heeft Stan Ratliff (sratliff) het volgende > geschreven: > > > > > On Jan 17, 2013, at 2:07 AM, Henning Rogge wrote: > > > >> On 01/17/2013 12:16 AM, Charles E. Perkins wrote: > >>> People, including me, use TLVs because they are great for > >>> many purposes. Please note that there is no problem to > >>> have positional information in TLVs. > >> > >> To come back to XML, you would not do positional informations in XML... > and I think you shouldn't do this in RFC5444 either. > > > > +1 > > > > I have no specific scenario in mind, but creating positional > requirements could be "kiss of death" for routers, especially if the > processing leads to data moves inside a packet. By that, I mean if you have > a scenario where you have a sound, good packet partially built, *then* come > up on a situation where you have to reorganize the packet to add an > additional, position-dependent TLV, you've just taken a huge performance > hit in order to shuffle the data around. It's much better to just slap > another TLV onto the end of the packet, and keep on moving. > > > > Regards, > > Stan > > > >> > >>>> How many of them are TLV based formats? > >>> > >>> Given that TLVs can be (i) binary and (ii) positional, I'm not sure > >>> exactly what you are asking, and I do not know just what the > >>> percentages are. But, Mobile IP and Diameter use TLVs. > > [snip] > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --14dae9cfcba697ceee04d37ee8af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Teco,

On Thu, Jan 17, 2013 at 8:17 AM, Te= co Boot <teco@inf-net.nl> wrote:
+/- 1

This positional vs. TLV discussion is getting somewhat black and white. Loo= king out of my window, I see a grey world. Ahh, Dutch foggy weather...
<= /blockquote>

I can't say the same about the weather here in Cal= ifornia ;-)

=A0

Encode each and every bit in a TLV, where such bits are in a group, isn'= ;t that smart. An array of bits makes lots of sense. Positional encoded inf= o is in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 bits and the = exponent & mantissa fields).

I think the discussion was about a fixed position of = addresses that are associated with some meaning (e.g., 1st position in the = 1st address block means destination address); not about representation of a= TLV value (e.g., how to interpret the value of the LINK_METRIC TLV).
=A0

So I can't see why it is bad to use a TLV "payload" value wit= h multiple fields. Could be multiple addresses.

That = is already supported with TLVs, both by using start- and stop-index as well= as multi-value TLVs, and does not require positional assumptions of addres= ses in RFC5444 messages.


Best regards
Ulrich

=A0
Yes, address block TLV is another tool that could be used. It is up to t= he protocol designers to make smart decisions.

Teco


Op 17 jan. 2013, om 16:03 heeft Stan Ratliff (sratliff) het volgende geschr= even:

>
> On Jan 17, 2013, at 2:07 AM, Henning Rogge wrote:
>
>> On 01/17/2013 12:16 AM, Charles E. Perkins wrote:
>>> People, including me, use TLVs because they are great for
>>> many purposes. =A0Please note that there is no problem to
>>> have positional information in TLVs.
>>
>> To come back to XML, you would not do positional informations in X= ML... and I think you shouldn't do this in RFC5444 either.
>
> +1
>
> I have no specific scenario in mind, but creating positional requireme= nts could be "kiss of death" for routers, especially if the proce= ssing leads to data moves inside a packet. By that, I mean if you have a sc= enario where you have a sound, good packet partially built, *then* come up = on a situation where you have to reorganize the packet to add an additional= , position-dependent TLV, you've just taken a huge performance hit in o= rder to shuffle the data around. It's much better to just slap another = TLV onto the end of the packet, and keep on moving.
>
> Regards,
> Stan
>
>>
>>>> How many of them are TLV based formats?
>>>
>>> Given that TLVs can be (i) binary and (ii) positional, I'm= not sure
>>> exactly what you are asking, and I do not know just what the >>> percentages are. =A0But, Mobile IP and Diameter use TLVs.
> [snip]
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--14dae9cfcba697ceee04d37ee8af-- From charliep@computer.org Thu Jan 17 10:21:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7FA21F8830 for ; Thu, 17 Jan 2013 10:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apCGQBihMWsS for ; Thu, 17 Jan 2013 10:21:37 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 72ABF21F882E for ; Thu, 17 Jan 2013 10:21:37 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tvu5o-0002TV-NF; Thu, 17 Jan 2013 13:21:36 -0500 Message-ID: <50F8412A.9070202@computer.org> Date: Thu, 17 Jan 2013 10:21:30 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8659e2a963f35a4d10ac8964c6731784c4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: "" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:21:38 -0000 Hello Stan, On 1/17/2013 7:03 AM, Stan Ratliff (sratliff) wrote: > > I have no specific scenario in mind, but creating positional requirements could be "kiss of death" for routers, especially if the processing leads to data moves inside a packet. By that, I mean if you have a scenario where you have a sound, good packet partially built, *then* come up on a situation where you have to reorganize the packet to add an additional, position-dependent TLV, you've just taken a huge performance hit in order to shuffle the data around. It's much better to just slap another TLV onto the end of the packet, and keep on moving. This comment does not apply to the current design of originator/target ordering in the AODVv2 AddrBlk. It's not the *position* of any TLV that was under discussion, nor the ordering of the TLVs. In the current design, it's expected that new TLVs or AddrBlks will be added just as you suggest. -- Regards, Charlie P. From charliep@computer.org Thu Jan 17 10:29:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D506E21F8853 for ; Thu, 17 Jan 2013 10:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmsOKHOlihUn for ; Thu, 17 Jan 2013 10:29:07 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1F21F8846 for ; Thu, 17 Jan 2013 10:29:07 -0800 (PST) Received: from [216.123.155.211] (helo=[172.16.1.120]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TvuD4-00087c-Mm; Thu, 17 Jan 2013 13:29:06 -0500 Message-ID: <50F842ED.8080200@computer.org> Date: Thu, 17 Jan 2013 10:29:01 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad868d226e7319ed30be526568ca4bb1113a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.123.155.211 Cc: "" Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:29:08 -0000 Hello Stan, RFC 5444 doesn't handle address overlap. Does your comment also apply to address overlap in OLSRv2 and DLEP? Interestingly, in the scenarios under discussion, we might have to qualify addresses with *two* prefixes, not just one. Or, if the problem is multi-level, even more prefixes! The solutions for address overlap I have encountered can be applied to [manet], but, as they say, it's complicated. On 1/17/2013 6:57 AM, Stan Ratliff (sratliff) wrote: > On Jan 16, 2013, at 8:47 PM, Charles E. Perkins wrote: > > > > > I'm going to be in complete DISagreement about "writing the problem away" with regard to the above applicability statement. As the thread to this point has shown, address overlap is going to occur. It's extremely prevalent in the networks I work on. Employing a lot of poly-syllabic geek-speak that will parse down to "Don't do that." doesn't help users very much. To be honest, I don't have the answer, but I think this topic deserves some more discussion. I would suggest that we take Sue's point #3 and amend slightly to "We'll work on this some now and see if there's a reasonable approach. If not, it may be something we defer, as it brings up thoughts of the working group whose name shall not be mentioned."… ;-) > > -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Thu Jan 17 11:12:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC41B21F84F0 for ; Thu, 17 Jan 2013 11:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUb6soCvFYJQ for ; Thu, 17 Jan 2013 11:12:42 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id EB77D21F8479 for ; Thu, 17 Jan 2013 11:12:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="255923627" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jan 2013 19:12:41 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0HJCeae005249 for ; Thu, 17 Jan 2013 19:12:41 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6958"; a="3681512" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 17 Jan 2013 19:12:40 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 17 Jan 2013 19:12:41 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Stability versus gateway specification Thread-Index: AQHN2JgbI7Pzgc9b0Ua1dKF+h63nJpgWWNkAgCzGTACAAMUIAIAGPXEAgAAEMQCAAAbqgIAAAvoAgALAhoCAAAfXgIAA3M4AgAA6/ICAAAwZgA== Date: Thu, 17 Jan 2013 19:12:40 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> <50F842ED.8080200@computer.org> In-Reply-To: <50F842ED.8080200@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:12:47 -0000 What's meant here by address overlap? An example would help. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 17 January 2013 18:29 To: Stan Ratliff (sratliff) Cc: Subject: Re: [manet] Stability versus gateway specification ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Stan, RFC 5444 doesn't handle address overlap. Does your comment also apply to address overlap in OLSRv2 and DLEP? Interestingly, in the scenarios under discussion, we might have to qualify addresses with *two* prefixes, not just one. Or, if the problem is multi-level, even more prefixes! The solutions for address overlap I have encountered can be applied to [manet], but, as they say, it's complicated. On 1/17/2013 6:57 AM, Stan Ratliff (sratliff) wrote: > On Jan 16, 2013, at 8:47 PM, Charles E. Perkins wrote: > > > > > I'm going to be in complete DISagreement about "writing the problem away"= with regard to the above applicability statement. As the thread to this po= int has shown, address overlap is going to occur. It's extremely prevalent = in the networks I work on. Employing a lot of poly-syllabic geek-speak that= will parse down to "Don't do that." doesn't help users very much. To be ho= nest, I don't have the answer, but I think this topic deserves some more di= scussion. I would suggest that we take Sue's point #3 and amend slightly to= "We'll work on this some now and see if there's a reasonable approach. If = not, it may be something we defer, as it brings up thoughts of the working = group whose name shall not be mentioned.". ;-) > > --=20 Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** From abdussalambaryun@gmail.com Thu Jan 17 12:27:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9421F892F for ; Thu, 17 Jan 2013 12:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFMWHGpmhY-8 for ; Thu, 17 Jan 2013 12:27:35 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id B1A5321F8574 for ; Thu, 17 Jan 2013 12:27:35 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id fo14so2734973vcb.36 for ; Thu, 17 Jan 2013 12:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B9AH1S+eL4M1onKtnGrKdzqgTrE/fCPYayWKaqC+rlw=; b=uP2GB3nlW1nV50GHuSIe/ArBsjUA4sM2dLQ4MnCi9N4JsugVLZeNJ5QsdvrL08Ct1P q4/ORrQnZZcQwuXXHcFaurTrctoUZGMy9oSaluFjdRgUNFV7Zc4igKotmLFqp5xaQmvB OuiAYZDYAV45/IsfW357pBcOXuKVA2AvDl6QBwSQl9W3a8qIKWdIXx99TS8AEwwEGFgI 0yFlCU4+gy+iwOVp041Y+SzjVs/bLqYg6yclYIVzBYk2cKQT+O8llEZXLr6ZER3dmgw+ S2muHZaISOb8oq59TwGgu7r7D2DYENE7nYHjrRB3Rk974folzUDDTYaF8ACds8Mtl84I lbsA== MIME-Version: 1.0 X-Received: by 10.52.76.73 with SMTP id i9mr6101941vdw.25.1358454455130; Thu, 17 Jan 2013 12:27:35 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 12:27:34 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> Date: Thu, 17 Jan 2013 21:27:34 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 20:27:40 -0000 I agree with all your comments, hope we start going through reactive protocol design in relation with these format methods, AB On 1/17/13, Teco Boot wrote: > +/- 1 > > This positional vs. TLV discussion is getting somewhat black and white. > Looking out of my window, I see a grey world. Ahh, Dutch foggy weather... > > Encode each and every bit in a TLV, where such bits are in a group, isn't > that smart. An array of bits makes lots of sense. Positional encoded info is > in OLSRv2 already (LINK_METRIC TLV, 2 octets which are 4 bits and the > exponent & mantissa fields). > > So I can't see why it is bad to use a TLV "payload" value with multiple > fields. Could be multiple addresses. Yes, address block TLV is another tool > that could be used. It is up to the protocol designers to make smart > decisions. > > Teco > > > Op 17 jan. 2013, om 16:03 heeft Stan Ratliff (sratliff) het volgende > geschreven: > >> >> On Jan 17, 2013, at 2:07 AM, Henning Rogge wrote: >> >>> On 01/17/2013 12:16 AM, Charles E. Perkins wrote: >>>> People, including me, use TLVs because they are great for >>>> many purposes. Please note that there is no problem to >>>> have positional information in TLVs. >>> >>> To come back to XML, you would not do positional informations in XML... >>> and I think you shouldn't do this in RFC5444 either. >> >> +1 >> >> I have no specific scenario in mind, but creating positional requirements >> could be "kiss of death" for routers, especially if the processing leads >> to data moves inside a packet. By that, I mean if you have a scenario >> where you have a sound, good packet partially built, *then* come up on a >> situation where you have to reorganize the packet to add an additional, >> position-dependent TLV, you've just taken a huge performance hit in order >> to shuffle the data around. It's much better to just slap another TLV onto >> the end of the packet, and keep on moving. >> >> Regards, >> Stan >> >>> >>>>> How many of them are TLV based formats? >>>> >>>> Given that TLVs can be (i) binary and (ii) positional, I'm not sure >>>> exactly what you are asking, and I do not know just what the >>>> percentages are. But, Mobile IP and Diameter use TLVs. >> [snip] >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Jan 17 12:39:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3002721F860A for ; Thu, 17 Jan 2013 12:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olXDjoxCIL1o for ; Thu, 17 Jan 2013 12:39:51 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8221F85AF for ; Thu, 17 Jan 2013 12:39:51 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id fo14so2731540vcb.22 for ; Thu, 17 Jan 2013 12:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7kuXs/ScQQtBIlU0QcJoiPZSwiA1RnduC9Yq6KdDqo4=; b=UMv+wKnuFxV25w5BjlmHA1ULeAidEV3mWlLTM8XOlRzgEZI60dzE6sbPcCZEzHin0k GI3AqGEMuzczbdYFzMqZYsU3CILYrO/XGu9RjiKxUwGenhmqaA+mGmGg+dDUK4gjIucq qz1BMXdtz9cERzCKnyQTwtseO8L+T7SQdCsc75LNaNLwH+1RfZsNh0TKbuApNq/7Nj2L 5GSTpoZaJdgxusrVaYC7oph5K5eCphocp8GYXIRpvjpU/pgKr35MpaJuibNySnis34wh x3dPH0hF45d9mfc0LsV2EfSEhZVurgVMix9jWTS17NAQvrTtpd8RYGBXlEAu4ZROfz34 H80w== MIME-Version: 1.0 X-Received: by 10.220.247.136 with SMTP id mc8mr6864039vcb.44.1358455190990; Thu, 17 Jan 2013 12:39:50 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 12:39:50 -0800 (PST) In-Reply-To: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> Date: Thu, 17 Jan 2013 21:39:50 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 20:39:52 -0000 Hi Chris, comments in line; On 1/17/13, Dearlove, Christopher (UK) wrote: > Not random, but unspecified, and permitted to be ordered for efficiency as > the message constructor chooses. Not the same. I now understand the better way to call it, thanks, > > (Why can order affect efficiency? Because the most efficient way of > attaching TLVs is with the addresses the TLV applies to grouped together. It is good explaination but I would like to know the attached function to such TLV so I can know how to measure gain (who defines the game). > Whether the gain is significant depends on various details. Note that, > despite using multiple TLVs, this is possible in NHDP/OLSRv2. However in the > simplest cases there is no significant gain due to order - except not having > multiple address blocks is usually a gain, unless e.g. you have two or more > quite different types of address. Even then it may not be a gain.) > Thanks for that it added to my knowledge of NHDP which is important in routing. However, the above is right only if we are ignoring the importance of the protocol processing and states. The RFC5444 ignores the issues because it was designed for all routings, and we should think in the above way when designing general messaging, but I think if we design in one protocol we should go through another direction. AB From abdussalambaryun@gmail.com Thu Jan 17 12:59:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D35221F87EE for ; Thu, 17 Jan 2013 12:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZpjHcqmR4rs for ; Thu, 17 Jan 2013 12:59:14 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC4821F86B1 for ; Thu, 17 Jan 2013 12:59:14 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fl15so3004657vcb.32 for ; Thu, 17 Jan 2013 12:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fkUtIP0XxqQnPclyJ4Y0vGq7tzTXDEwWixESGV/JRoc=; b=lN/Bk3IiamOJgXgjc61CkfMUJ8EyE4ReCsw6l6Wt6tkVG1VqLaW9Hwh2arKnymqEep KS4CDFpvx6QLMkzuf/qLagkrgcnF8ZfFRM9ir2FYE+Tvwi4rBoQCfFMAcF2y2DwDsqVu wBJD3nPsFOI2jALNcUnVZVNTLFpavI1t0s5poqzvm/4Q85cWo8kjuqnDcuEJwwon97Ms 73KsVm7F4CsrncHCgncOERF7CzY7T8p3uco0sjI4fCdkeljjAjI3qq1mEQRKLxrVC8wt D5SLB9bbGf2Pin8B6K3GVsIOhdnSAg4vkUpoEKpT8JJmyRGb1OB8TqrnLrIN163UaWx3 YxyQ== MIME-Version: 1.0 X-Received: by 10.52.27.50 with SMTP id q18mr6293037vdg.20.1358456353481; Thu, 17 Jan 2013 12:59:13 -0800 (PST) Received: by 10.220.145.5 with HTTP; Thu, 17 Jan 2013 12:59:13 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50F6E81A.9050802@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF0F8D@xmb-aln-x03.cisco.com> <50F7A6D2.8010008@fkie.fraunhofer.de> Date: Thu, 17 Jan 2013 21:59:13 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 20:59:15 -0000 Hi Chris I agree that don't like XML examples and want better examples to know best way to design. however, Why you abstract the addresses and attribute as you mentioned, from the protocol message? or maybe I got it wrong :( AB On 1/17/13, Dearlove, Christopher (UK) wrote: > I will say that OLSRv2 split into five documents (not counting metrics > rationale, MIB, or future security documents). In my ideal world in which I > (and my co-suthors) had unlimited time, I would have had two more, one of > which would have been a separation between a message specification in terms > of addresses and attributes, and a mapping of the latter to 5444. (The > other, just for interest, is that OLSRv2's processing and forwarding engine > is potentially reusable outside OLSRv2.) Whether XML is the best > intermediate form could be debated - and it might be important to understand > whether the XML is being used as a presentational approach, or really > intended for use. It has drawbacks in both cases, as well as advantages. The > major dangers I see are people thinking you must use XML in your > implementation - really you shouldn't even hint that - and taht the XML > might itself obscure matters in that intermediate step. Arguably XML isn't > that intermediate step, but another thing that the abstract "addresses and > attributes" could be coded as. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > From shares@ndzh.com Thu Jan 17 18:20:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062021F8B5B for ; Thu, 17 Jan 2013 18:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.641 X-Spam-Level: X-Spam-Status: No, score=0.641 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYUzN-O0DVxg for ; Thu, 17 Jan 2013 18:20:33 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9817F21F8B48 for ; Thu, 17 Jan 2013 18:20:32 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Stan Ratliff \(sratliff\)'" , "'Charles E. Perkins'" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> Date: Thu, 17 Jan 2013 21:20:29 -0500 Message-ID: <003501cdf522$62c95fb0$285c1f10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHudT1uDINtjmojwEwHKsjhtjvdPwHRflryApinT5kCcrN/6gM4TVV2A4Sb2okBswFHKAE44h6SAmw8laYCFvx8mgEovOEZAf0bD/wB/dVwTAIg2blsAbvazfkB2pMXZQKsikCWAnEe6qcC4H5JQpbOQlow Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: manet@ietf.org Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 02:20:34 -0000 Stan: Can you help me with a bit of clarity on your instructions in the email statement below? Neither Charlie nor I have suggested insertion of the prefix cannot be done. We only asked "do you want to do it now?" My understanding from the LOADng and from the AODV2 participants was they were trying to wrap of the document at this stage, and head toward RFC without the external prefix insertion. If you want to add prefix insertion from multiple external points, IHMO based on trying it in another forum (IEEEE) I suspect you are looking at year+ effort. If you are looking for "some", I am concerned to scope the "some" process to some defined set of objectives. A sample set of objectives would be: a) create a problem you are trying to solve b) determine solution criteria, c) Gap analysis on existing efforts, d) summarize the requirements, e) suggest a few solutions, and f) determine if "some" is worth slowing down. How does this fit with your design team plans? Can you provide a scope of work plan and a timeline you'd like to have for the reactive protocol work. Thank you, Sue Hares [snip] with email message below: I'm going to be in complete DISagreement about "writing the problem away" with regard to the above applicability statement. As the thread to this point has shown, address overlap is going to occur. It's extremely prevalent in the networks I work on. Employing a lot of poly-syllabic geek-speak that will parse down to "Don't do that." doesn't help users very much. To be honest, I don't have the answer, but I think this topic deserves some more discussion. I would suggest that we take Sue's point #3 and amend slightly to "We'll work on this some now and see if there's a reasonable approach. If not, it may be something we defer, as it brings up thoughts of the working group whose name shall not be mentioned.". ;-) [snip off] -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: Thursday, January 17, 2013 9:58 AM To: Charles E. Perkins Cc: Susan Hares; Subject: Re: [manet] Stability versus gateway specification On Jan 16, 2013, at 8:47 PM, Charles E. Perkins wrote: > > Hello Sue, > > I am fine with your three points. > > The WG manet protocols are applicable to networks for which the nodes > populating the networks are known to have unique addresses. So it > would probably break the WG specifications to have non-unique net-10 > addresses. > > I think that it probably makes sense to improve the "Applicability > Statement" to restrict AODVv2 for deployment only in networks where > the nodes have unique IP addresses. OK, I'm going to admit to writing this response without reading the "down thread" emails (man, we've gotten chatty recently). I'm going to be in complete DISagreement about "writing the problem away" with regard to the above applicability statement. As the thread to this point has shown, address overlap is going to occur. It's extremely prevalent in the networks I work on. Employing a lot of poly-syllabic geek-speak that will parse down to "Don't do that." doesn't help users very much. To be honest, I don't have the answer, but I think this topic deserves some more discussion. I would suggest that we take Sue's point #3 and amend slightly to "We'll work on this some now and see if there's a reasonable approach. If not, it may be something we defer, as it brings up thoughts of the working group whose name shall not be mentioned.". ;-) Regards, Stan > > Regards, > Charlie P. > > On 1/16/2013 5:19 PM, Susan Hares wrote: >> Henning and Charlie: >> >> Sorry for delay in responding.... >> >> The 10.0.0.0/8 example will occur in the wild. People will pull out >> their manet router with factory defaults. >> >> I have seen routing policy that forbids 10.0.0.0/8 in a network >> (Henning's example). >> I have also seen Charlie's example where the people blocked each other. >> >> I'm sorry to be dense here. Your two behaviors simply restate the >> basics of routing and policy. >> If you allow external route or static route insertion, these are possible. >> >> I thought the answer you both gave me was: >> >> 1) this is insertion of routes into reactive protools is useful but >> hard, >> 2) current manet protocols will go on without prefix insertion, >> 3) We'll work next on as a specific topic. >> >> I look forward to working on the route insertion at the right time >> with both of you. >> >> >> Sue >> >> > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From shares@ndzh.com Thu Jan 17 18:24:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4BD21F88E8 for ; Thu, 17 Jan 2013 18:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.567 X-Spam-Level: * X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKNO4W9UirCP for ; Thu, 17 Jan 2013 18:24:11 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BDEF321F890D for ; Thu, 17 Jan 2013 18:24:10 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.123.155.211; From: "Susan Hares" To: "'Henning Rogge'" , "'Abdussalam Baryun'" References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> In-Reply-To: Date: Thu, 17 Jan 2013 21:24:06 -0500 Message-ID: <003701cdf522$e466adc0$ad340940$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJisPCRMT8vkNWydoI1/6vlGuxC1QIYjcQ0AfyrF8oBcD5iiAFRD6Z1AeY5OX8CD3bcWwHGaZeiAoiNRIoCH44+l5aa9mpw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 02:24:11 -0000 Henning: (smile) Link-state protocols with TLVs make additions easy to consider. Sue -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: Tuesday, January 15, 2013 2:23 PM To: Abdussalam Baryun Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker I have quite a few extensions planned for OLSRv2, all of them easy to do because of the TLV format. Henning Rogge From henning.rogge@fkie.fraunhofer.de Thu Jan 17 22:52:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE0B21F8A6B for ; Thu, 17 Jan 2013 22:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18JQu7Nu-kEn for ; Thu, 17 Jan 2013 22:52:20 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id AB90C21F8587 for ; Thu, 17 Jan 2013 22:52:18 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tw5oE-0003xT-UR; Fri, 18 Jan 2013 07:52:14 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tw5oE-0002Kn-Rg; Fri, 18 Jan 2013 07:52:14 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 18 Jan 2013 07:52:14 +0100 Message-ID: <50F8F117.9070209@fkie.fraunhofer.de> Date: Fri, 18 Jan 2013 07:52:07 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teco Boot References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060709020603080203090705" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16516/Fri Jan 18 00:39:46 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 06:52:21 -0000 --------------ms060709020603080203090705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/17/2013 05:17 PM, Teco Boot wrote: > +/- 1 > > This positional vs. TLV discussion is getting somewhat black and > white. Looking out of my window, I see a grey world. Ahh, Dutch foggy > weather... > > Encode each and every bit in a TLV, where such bits are in a group, > isn't that smart. An array of bits makes lots of sense. Positional > encoded info is in OLSRv2 already (LINK_METRIC TLV, 2 octets which > are 4 bits and the exponent & mantissa fields). > > So I can't see why it is bad to use a TLV "payload" value with > multiple fields. Could be multiple addresses. Yes, address block TLV > is another tool that could be used. It is up to the protocol > designers to make smart decisions. I think the discussion what to put into the value of a TLV is quite=20 different from the one we had before. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060709020603080203090705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTgwNjUyMTJaMCMGCSqGSIb3DQEJBDEWBBTkaVqHxiNKPhLtBILRPCdw2OhdlDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEATCBYMTs+9E1BY5/yaJ3A7umOMenyrKYs5dUX2UlCH5pA SIwtzPvlaHUjEB9W1Nn2xV9x1jhpjzAfvFSLvRgmHAoZFmcHpqSvi29PikhactDG/PsLJJfv pE/vvoHUcoLMsQi1xnnq1EFTtCjU1800mHa02Ym7LvYPTNT2QvmS9pOZuUsYvUEjoq0Rpqmt 3JgbbIRVU2jaZGFsC/vunMGRz8eiDvN+hF+XcJZEkON3u5UJakAM1VTEo2X8zpAdW6tiSRf8 5nEN8LDY4yrBas48eDCI1j6FMCnD25gKlv6+/HSG9Scs//aNnYCm3egsrPhv8GvPUOPsG+lK O+FlsohKwwAAAAAAAA== --------------ms060709020603080203090705-- From henning.rogge@fkie.fraunhofer.de Thu Jan 17 22:56:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D624D21F8A52 for ; Thu, 17 Jan 2013 22:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGZkcGkFIVH9 for ; Thu, 17 Jan 2013 22:56:12 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9221F8A49 for ; Thu, 17 Jan 2013 22:56:11 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tw5s2-0005ZC-TO for manet@ietf.org; Fri, 18 Jan 2013 07:56:10 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tw5s2-0002RS-Qh for manet@ietf.org; Fri, 18 Jan 2013 07:56:10 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 18 Jan 2013 07:56:10 +0100 Message-ID: <50F8F209.6030301@fkie.fraunhofer.de> Date: Fri, 18 Jan 2013 07:56:09 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> <50F842ED.8080200@computer.org> In-Reply-To: <50F842ED.8080200@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080003000109010004000408" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16516/Fri Jan 18 00:39:46 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 06:56:13 -0000 --------------ms080003000109010004000408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 01/17/2013 07:29 PM, Charles E. Perkins wrote: > > Hello Stan, > > RFC 5444 doesn't handle address overlap. I am not sure how to parse that statement. RFC5444 "handles" (spells:=20 transports) all kind of prefixes, with the option the leave out a full=20 length prefix. > Does your comment also apply to address overlap in OLSRv2 > and DLEP? > > Interestingly, in the scenarios under discussion, we might > have to qualify addresses with *two* prefixes, not just one. > Or, if the problem is multi-level, even more prefixes! Thats already possible for RFC5444, you just put in both prefixes, both=20 with the same address. As an example, its totally okay to have 0.0.0.0/0 and 0.0.0.0/1 in your=20 attached networks on OLSRv2 (we have this in a few Funkfeuer networks=20 based on OLSRv1 too). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080003000109010004000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTgwNjU2MDlaMCMGCSqGSIb3DQEJBDEWBBQzXDSsSSGxFuHOvgv3bKIiRYm38TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEApA1O14VG3OAEwuu8TPUZIU1TpMTVxMxnGyAdyQ7Jz9T9 DgwuC+Jmj0hT29BKeJn/F83QHrMDgNI1Sud+rUXVYbr5/SiD9feuzSv5xkreoB+SDSYKFzyf FcsBo3m8+3JZAKwZgtCLzth/K3fgM0OFPiwxlUfP3A5vieytiiQqTK6OG9iFEM/5aGY+3Hfx 1kygCkwywMQwrKT6+JI6mR9LEOyEy9KicHj+7wrxdRBChDdBWDGuMLA/f/2xs3myyzFO04Z6 icXYOTNgVk8x9H0kmXt1CCBXbrd3CYEVirYce8lhCs+wiffaUwiPSFnpyyBBIXc2vsAZJ5mi XGC0USrPMQAAAAAAAA== --------------ms080003000109010004000408-- From henning.rogge@fkie.fraunhofer.de Thu Jan 17 23:44:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FE321F89CB for ; Thu, 17 Jan 2013 23:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yfm2hL5ccG3 for ; Thu, 17 Jan 2013 23:44:29 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6AD21F8945 for ; Thu, 17 Jan 2013 23:44:27 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tw6cj-0003iy-VR for manet@ietf.org; Fri, 18 Jan 2013 08:44:25 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tw6cj-0003dI-Sl for manet@ietf.org; Fri, 18 Jan 2013 08:44:25 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 18 Jan 2013 08:44:25 +0100 Message-ID: <50F8FD58.5030903@fkie.fraunhofer.de> Date: Fri, 18 Jan 2013 08:44:24 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> <003501cdf522$62c95fb0$285c1f10$@ndzh.com> In-Reply-To: <003501cdf522$62c95fb0$285c1f10$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020206090708060903090806" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16516/Fri Jan 18 00:39:46 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 07:44:29 -0000 --------------ms020206090708060903090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/18/2013 03:20 AM, Susan Hares wrote: > Stan: > > Can you help me with a bit of clarity on your instructions in the email= > statement below? > > Neither Charlie nor I have suggested insertion of the prefix cannot be = done. > We only asked "do you want to do it now?" My concern is about section 10 of DYMO draft v25, called "Simple=20 Internet Attachment". Its low on details and I am not convinced it does work without problems=20 in all usecases Charly has described for AODVv2. If the AODVv2 MANET use "randomized addresses", how should the IAR=20 decide whats a "Internet Destination" and what not? Thats exactly the=20 issue I was talking about when I mentioned "blackhole" routes. To be sure that an AODVv2 router does NOT respond to a request to a host = route for the MANET, it either needs to know all MANET addresses or at=20 least their common prefix. Otherwise the RREQ might just get lost towards the real node and the IAR = will answer the request, blocking further access to the real destination.= Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020206090708060903090806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTgwNzQ0MjRaMCMGCSqGSIb3DQEJBDEWBBQOM8jefSWuK8Je59+vvdoB1sXkhTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAXahTVSmt0m8mnwNjqGQF7xrIu6GWU6HgmB6VG4HNDHtC K9HWoKMcOoIr0Fkzbw+LJwK+1OWHD283qgaR56uKwm5+2znxdV3zPRAevJYWsMDWEueflOx1 hhuFkb5RInZJqsPhq4lGqypNc0CdTBO4k3JDC9MOoTGQ/9o63HVZKuZABd2gC8zMXsVzFsvt svwNqVnWLFTYFAcxIvpNVmKNLFdQVrIueRQnPQ1lSp32cn6YI0qAgoHboAdjcWKTLzox6F/x +lC6sjE6y0AGYASz2cXWYgaN5KsSxH1VFVSw1ts2EIyIHzVuCxIEYnHO3HZ65gK5J/aAiZZg PTWB1B3/kgAAAAAAAA== --------------ms020206090708060903090806-- From Chris.Dearlove@baesystems.com Fri Jan 18 02:01:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F8E21F88EF for ; Fri, 18 Jan 2013 02:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElqMCMDLkGK6 for ; Fri, 18 Jan 2013 02:01:58 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01621F8865 for ; Fri, 18 Jan 2013 02:01:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,491,1355097600"; d="scan'208";a="301534228" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 18 Jan 2013 10:01:54 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0IA1r9H021459 for ; Fri, 18 Jan 2013 10:01:53 GMT X-IronPort-AV: E=McAfee;i="5400,1158,6958"; a="3943031" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 18 Jan 2013 10:01:53 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 18 Jan 2013 10:01:53 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] Hares Technical Question 2: order of address in TLV Thread-Index: Ac3yFhOratnXSvfpSO6Gc0VvxiKSKwAEYHeAAEgtlwAAA5b0gAAJSccAABFoyoAAH4iOgAAA2BGAABWo+1AAFkzTAAAb72Pg Date: Fri, 18 Jan 2013 10:01:53 +0000 Message-ID: References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 10:01:58 -0000 If you want to work out sizes, then step one is read and fully understand 5= 444. If you achieve that, you can do the rest. Your second paragraph is not clear, but if it means what I think it means, = I completely disagree. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: 17 January 2013 20:40 To: Dearlove, Christopher (UK) Cc: Charles E. Perkins; manet@ietf.org Subject: Re: [manet] Hares Technical Question 2: order of address in TLV ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, comments in line; On 1/17/13, Dearlove, Christopher (UK) wrot= e: > Not random, but unspecified, and permitted to be ordered for efficiency a= s > the message constructor chooses. Not the same. I now understand the better way to call it, thanks, > > (Why can order affect efficiency? Because the most efficient way of > attaching TLVs is with the addresses the TLV applies to grouped together. It is good explaination but I would like to know the attached function to such TLV so I can know how to measure gain (who defines the game). > Whether the gain is significant depends on various details. Note that, > despite using multiple TLVs, this is possible in NHDP/OLSRv2. However in = the > simplest cases there is no significant gain due to order - except not hav= ing > multiple address blocks is usually a gain, unless e.g. you have two or mo= re > quite different types of address. Even then it may not be a gain.) > Thanks for that it added to my knowledge of NHDP which is important in routing. However, the above is right only if we are ignoring the importance of the protocol processing and states. The RFC5444 ignores the issues because it was designed for all routings, and we should think in the above way when designing general messaging, but I think if we design in one protocol we should go through another direction. AB ******************************************************************** 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. ******************************************************************** From abdussalambaryun@gmail.com Fri Jan 18 08:36:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEA621F8742 for ; Fri, 18 Jan 2013 08:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgnEYaxoLHvE for ; Fri, 18 Jan 2013 08:36:09 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7778D21F86A9 for ; Fri, 18 Jan 2013 08:36:09 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so3374876vbb.9 for ; Fri, 18 Jan 2013 08:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B9GkbwojZVywrhxxTEbQlAgN4CDKjfPUJi5PrZurno0=; b=NvDKWpEgNYot5Gy2qNHUrjuderN787jqvco22Fsq18AqvZETF+EanNFPS34UFYQzww SZErj0hCqTCQxuG7MniSQo0zRPsXxFf0O3J/enHDBqh1m8iF9ZKe0QygA23jxqZqMSNt 1N6VIrjsjOy2jn6LZvdhHyoUqW9ennfZWr5MoTx0CtM4ERxf7QKmNq8xCLm8HmXpITCg lmPxWhI9pyfrh39zOGPXDkH6QXAfpsdojkrj2gq76ULl0mzPg6XKIcKqGhnqv41mhGuR 0GfHzliNGjkn3MGBFDf+zAwXYfQH+hlPMxxYaSbSa6c2xFqNh2x3clXUchnEfvLMxgpx /uOw== MIME-Version: 1.0 X-Received: by 10.52.27.50 with SMTP id q18mr9158046vdg.20.1358526963666; Fri, 18 Jan 2013 08:36:03 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 18 Jan 2013 08:36:03 -0800 (PST) In-Reply-To: <003501cdf522$62c95fb0$285c1f10$@ndzh.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF27C64@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A77230F7F58@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF2BBB4@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7723100165@xmb-rcd-x02.cisco.com> <50C8BA7E.8050200@computer.org> <50C8CF75.1090406@computer.org> <50C98640.7010001@fkie.fraunhofer.de> <50EF1586.9060405@computer.org> <50EFBACE.3040104@fkie.fraunhofer.de> <50F4F6D6.2030007@computer.org> <50F4FA5A.2040507@fkie.fraunhofer.de> <50F50027.3040801@computer.org> <50F502A6.2010402@fkie.fraunhofer.de> <002901cdf450$b5886bb0$20994310$@ndzh.com> <50F75839.5000104@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1F5A@xmb-aln-x03.cisco.com> <003501cdf522$62c95fb0$285c1f10$@ndzh.com> Date: Fri, 18 Jan 2013 17:36:03 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Stability versus gateway specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:36:10 -0000 Hi Sue and All, Thanks for this, I agree that we need this, my comments in line, On 1/18/13, Susan Hares wrote: > A sample set of objectives would be: > > a) create a problem you are trying to solve > b) determine solution criteria, > c) Gap analysis on existing efforts, > d) summarize the requirements, > e) suggest a few solutions, and > f) determine if "some" is worth slowing down. > > How does this fit with your design team plans? Can you provide a scope of > work plan and a timeline you'd like to have for the reactive protocol work. For me I recommend to have the new reactive protocol done within 6 months milestone to submit, as we already have the ideas checked, but maybe we need more discussions, however, don't mind what the chair think best as long they make the decision not later than the next meeting. My suggestion scope for reactive protocol, is not to include the gateway issue (which will make the protocol late). Regarding the WG plan, I think it will start with discussion and end with new drafts and milestones, even though I am still waiting of the update of our WG milestones. We ask the WG chairs to answer your suggestions, regarding planning, AB From teco@inf-net.nl Fri Jan 18 09:38:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325FC21F869F for ; Fri, 18 Jan 2013 09:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVXPbKSMl3Pc for ; Fri, 18 Jan 2013 09:38:37 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 027B421F85AC for ; Fri, 18 Jan 2013 09:38:36 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so1860791eek.20 for ; Fri, 18 Jan 2013 09:38:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qnUTbamTNfzOJBbWWAMWO8pDXcqIgtaT0qWltK2BHhE=; b=XY+thf/HfrgsJmTDGV9kwgP8xZBIZxO1hIciObLF9aURugxDeuOKQF1j0wOCYp8OZ9 KaBgXSO2dYyqGQNH05WictAnkZSq88sAh7G6PszCnskqKO4LX2ckqX76jRaIIyENMrcE 6byiEXTsZjOck4BE9qgLXBx/OxZ0IfyfDkHkYXpFaIvrryvXFKRCzO2wFNDNLbohFUOZ peGk+PwR0r1wXmOkboWWgo0W3PGbOqlQPXew8s+MriPOoxepiHpaq0clVhqqbGbXKDUz 8QRskIClHbCJcKUt686y/K3VBDQlRl7slu2v5NEK/ka6Sq/XoTqE7fzl+y+8RZ+vbT2D XPlg== X-Received: by 10.14.194.199 with SMTP id m47mr28469569een.11.1358530715381; Fri, 18 Jan 2013 09:38:35 -0800 (PST) Received: from [10.87.32.55] ([80.187.201.33]) by mx.google.com with ESMTPS id l3sm8266745een.14.2013.01.18.09.38.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 09:38:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <50F8F117.9070209@fkie.fraunhofer.de> Date: Fri, 18 Jan 2013 18:37:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F908442-AB09-45D7-8DE7-7A871AE82DE0@inf-net.nl> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> <50F8F117.9070209@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnZWDxQ+ECH5harx4z38BuPe64fX157fByfsEN7BqO0PYPsZlgOA709dmGDm50Eqetu6BFm Cc: " List" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:38:38 -0000 I just intended to say: in real world, nothing is black nor white. In address block TLVs, addresses are "an ordered set", "all sharing the = same Head and the same Tail". I have no idea what "ordered" means. = Intended to be ascending order, I presume. DYMO-25 violates this. Option for a DYMO-26: OrigNode can be . Other mandatory = singular fields can be put in a RteMsgTLV with positional info. I do not = say I prefer this, it is just a valid usage of RFC 5444. If it reduces = message size, it makes sense, doesn't it? Teco Op 18 jan. 2013, om 07:52 heeft Henning Rogge het volgende geschreven: > On 01/17/2013 05:17 PM, Teco Boot wrote: >> +/- 1 >>=20 >> This positional vs. TLV discussion is getting somewhat black and >> white. Looking out of my window, I see a grey world. Ahh, Dutch foggy >> weather... >>=20 >> Encode each and every bit in a TLV, where such bits are in a group, >> isn't that smart. An array of bits makes lots of sense. Positional >> encoded info is in OLSRv2 already (LINK_METRIC TLV, 2 octets which >> are 4 bits and the exponent & mantissa fields). >>=20 >> So I can't see why it is bad to use a TLV "payload" value with >> multiple fields. Could be multiple addresses. Yes, address block TLV >> is another tool that could be used. It is up to the protocol >> designers to make smart decisions. >=20 > I think the discussion what to put into the value of a TLV is quite = different from the one we had before. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From charliep@computer.org Fri Jan 18 10:13:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31CA21F87B9 for ; Fri, 18 Jan 2013 10:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6HSZGxcKsPz for ; Fri, 18 Jan 2013 10:13:24 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id C659321F86D2 for ; Fri, 18 Jan 2013 10:13:23 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TwGRO-0004Fx-Ci; Fri, 18 Jan 2013 13:13:22 -0500 Message-ID: <50F990BC.2070401@computer.org> Date: Fri, 18 Jan 2013 10:13:16 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Teco Boot References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> <50F8F117.9070209@fkie.fraunhofer.de> <9F908442-AB09-45D7-8DE7-7A871AE82DE0@inf-net.nl> In-Reply-To: <9F908442-AB09-45D7-8DE7-7A871AE82DE0@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86766ed82cc4757a20079717168da6c51f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: " List" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:13:24 -0000 Hello Teco, I wrote up that design in email early in 2012. The current design allows for IPv6 address abbreviation, which in my understanding was one of the prime motivations for RFC 5444. Henning has made an alternate proposal which may also preserve this feature and I will write it up early next week. Regards, Charlie P. On 1/18/2013 9:37 AM, Teco Boot wrote: > I just intended to say: in real world, nothing is black nor white. > > In address block TLVs, addresses are "an ordered set", "all sharing the same Head and the same Tail". I have no idea what "ordered" means. Intended to be ascending order, I presume. DYMO-25 violates this. > > Option for a DYMO-26: OrigNode can be . Other mandatory singular fields can be put in a RteMsgTLV with positional info. I do not say I prefer this, it is just a valid usage of RFC 5444. If it reduces message size, it makes sense, doesn't it? > > Teco > > Op 18 jan. 2013, om 07:52 heeft Henning Rogge het volgende geschreven: > >> On 01/17/2013 05:17 PM, Teco Boot wrote: >>> +/- 1 >>> >>> This positional vs. TLV discussion is getting somewhat black and >>> white. Looking out of my window, I see a grey world. Ahh, Dutch foggy >>> weather... >>> >>> Encode each and every bit in a TLV, where such bits are in a group, >>> isn't that smart. An array of bits makes lots of sense. Positional >>> encoded info is in OLSRv2 already (LINK_METRIC TLV, 2 octets which >>> are 4 bits and the exponent & mantissa fields). >>> >>> So I can't see why it is bad to use a TLV "payload" value with >>> multiple fields. Could be multiple addresses. Yes, address block TLV >>> is another tool that could be used. It is up to the protocol >>> designers to make smart decisions. >> I think the discussion what to put into the value of a TLV is quite different from the one we had before. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Straße 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From hrogge@googlemail.com Fri Jan 18 10:39:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F6121F869F for ; Fri, 18 Jan 2013 10:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbJnlzG9rzDP for ; Fri, 18 Jan 2013 10:39:36 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD021F84B2 for ; Fri, 18 Jan 2013 10:39:35 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id gm6so773061lbb.22 for ; Fri, 18 Jan 2013 10:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GRd7zl54UKkZSqn5y7KSphAHIMIrDVEJBqOy5nxWcco=; b=pEnyxlGGV7k9uCCn7PnuIieTUgFt3L1nH/6w1tn6ibAeqZME3n9LKzrnCvQl8Ln9Zh d8E1JKzsh6HX/duCXMstQ5m7h9wDQi6qjOwHAdCDFqM8FE69eyKnQe46Tfmglp1fjos/ JpYR9KeAtUmuKKljWSkV0ghedA9WnCZRpoV4TN1p6dP+SQXqSBBqj2cG1tLF2HT9kd3I MZjK2wJS9JKhr0CeEbWRo0TI/fDDf6yPT9is0cjIq0f0xQ0IEi+DCcqKd5YVM1+7E+sj L760zD4IXgahKN0V1+VgJAjWZNOA8wPi8IBZ/PoKDd7whPFRq0Kwy6cAZQhCZPSbIE47 eH7w== X-Received: by 10.152.102.177 with SMTP id fp17mr4685233lab.0.1358534374797; Fri, 18 Jan 2013 10:39:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Fri, 18 Jan 2013 10:39:13 -0800 (PST) In-Reply-To: <50F990BC.2070401@computer.org> References: <001201cdf216$1cbd6930$56383b90$@ndzh.com> <50F3B1A9.4050205@fkie.fraunhofer.de> <50F5960A.1020701@computer.org> <50F5EC76.5020503@computer.org> <50F6614B.5060909@fkie.fraunhofer.de> <50F734E9.7040701@computer.org> <50F7A31F.8070309@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF1FD9@xmb-aln-x03.cisco.com> <50F8F117.9070209@fkie.fraunhofer.de> <9F908442-AB09-45D7-8DE7-7A871AE82DE0@inf-net.nl> <50F990BC.2070401@computer.org> From: Henning Rogge Date: Fri, 18 Jan 2013 19:39:13 +0100 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Hares Technical Question 2: order of address in TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:39:37 -0000 On Fri, Jan 18, 2013 at 7:13 PM, Charles E. Perkins wrote: > Hello Teco, > > I wrote up that design in email early in 2012. > > The current design allows for IPv6 address abbreviation, which in > my understanding was one of the prime motivations for RFC 5444. > > Henning has made an alternate proposal which may also preserve > this feature and I will write it up early next week. We still have to look at the rest of the protocol messages, but I think most of them can be converted without wasting lots of bytes. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Fri Jan 18 20:54:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A821F8587 for ; Fri, 18 Jan 2013 20:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX9-5ltS9yBn for ; Fri, 18 Jan 2013 20:54:14 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id BC12921F878F for ; Fri, 18 Jan 2013 20:54:14 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so3208651vbb.10 for ; Fri, 18 Jan 2013 20:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=8wBSexdvjpKpbgABoa7gvDKzpzTy1CvaA6VuODl2Cvk=; b=08lea1K/Fh+2NXR9WtElLtJk/jNG/P/LZm+GMwcTA1TiE0w01sOD21In8BJTXeAGcP NHEVGkYosti1V7RAn7/7kDGuQ+ahR9CDFawYSIgoT0y2mzGbQvhHBhROJQVU27qp5dRO 1U1IMnCPgxE2kfktgnhy8QdkrhjXTGFs4i+Ze+tzAD6R8mxQiHCflmeHintHyQPHUqJy 4khIxzdszHag/jA0jgGB7JRLIbc83O/BNhhMozTI+UiJplQjAdzrO1xeQJ5u3COm/aKZ IJKhVYdNSl6L0W62cO+3JXehMcBXqlaZ7YOcolEzSH2dIpfIrvVU3ralRgx8PV96ttIl exFA== MIME-Version: 1.0 X-Received: by 10.52.76.170 with SMTP id l10mr10778494vdw.83.1358571254170; Fri, 18 Jan 2013 20:54:14 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 18 Jan 2013 20:54:14 -0800 (PST) In-Reply-To: References: <5F33561D-0F38-4E86-9D99-30B3034853CF@nicta.com.au> Date: Sat, 19 Jan 2013 05:54:14 +0100 Message-ID: From: Abdussalam Baryun To: =?ISO-8859-1?Q?Peter_H=F6fner?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob van van Glabbeek , manet@ietf.org, Wee Lum Tan Subject: Re: [manet] Incrementing Sequence numbers when not needed may yield non-optimal routes. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 04:54:15 -0000 Hi Peter, and All, I don't think increment is not needed, but we should not update in some conditions. My posts before that considered example [1] takes the node A sending twice RREQ. Another understanding of [1], if we consider that we have two originators S and A that originate RREQ1 and RREQ2 respectivily. Then DYMO router A will not update its route to D when it receives the later reply RREP1 as you described in last paragraph in [1] or in your papers. For DYMO-25, if we follow the specification to update we get to check-step 3 in the section 6.1, so no route update recommended. For LOADng router ( I may be wrong because still not read fully) may have the non-optimal problem, and node A updates route as per section 11.2 process step 8. I RECOMMEND the amendment as step conditions in DYMO, to check if the metric cost is larger with the sequence check. However, for LOADng, it may not get the problem only in very few situations, because the scenarios of example [1] assumes conditions of three sequence events as 1) node S request RREQ1 to D, 2) node A will request RREQ2 to D also only between the time start after topology chang, and after forward RREQ1 and ends before receiving RREP1 and 3) there is a long time between sending RREQ1 and receiving RREP1 as that RREP2 gets to A befor RREP1. These events makes the example special case and low possibility in a network, because usually route discovery have small time delay, and chance to have two requests at different time less than discovery. [1] http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN2.pdf Please provide me with your thoughts :) Regards Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++ On 1/11/13, Peter H=F6fner wrote: > Dear Abdussalam, > >> j node informs the the d node of such route otherwise how does the d >> node know the route to the source s. > > You are right; in our example we didn't take into account the uRREP > that j sends to d. Hence that example would not occur in the current > version of AODVv2. In fact, $d$ would send a RREP via $j$. > > We have another example however where no RREP by an intermediate > node is involved. It is presented at > http://www.cse.unsw.edu.au/~rvg/non-opt_incSQN2.pdf > > In that example, node D incrementing its own sequence number leads to > a sub-optimal route to D by A. Naturally, sub-optimal route can occur > all the time, but this is an example where we are worse off as a direct > consequence of D incrementing its own sequence number when issuing a RREP= . > > Does one of you know of an example where the destination incrementing > its own sequence number (other than a RREQ induced increment) has any > advantages? If so, one could try to analyse which problem is more > prevalent, and hence which incrementation strategy is best. > > Here, with a "RREQ induced increment" we mean that if the RREQ lists a > destination sequence number of n, indicating that n might be the latest > one that stopped working for the source of the request, then the > destination must increment its own sequence number to at least n+1. > > Cheers, > Peter, Rob, Marius and Wee Lum > > ________________________________ > > The information in this e-mail may be confidential and subject to legal > professional privilege and/or copyright. National ICT Australia Limited > accepts no liability for any damage caused by this email or its > attachments. > From abdussalambaryun@gmail.com Fri Jan 18 21:40:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D204421F85D2 for ; Fri, 18 Jan 2013 21:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf2B0UAO8BT3 for ; Fri, 18 Jan 2013 21:40:12 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 12CA121F879B for ; Fri, 18 Jan 2013 21:40:11 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id n11so2340737vch.19 for ; Fri, 18 Jan 2013 21:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=880sk87VdlNHz3uRf6lXBpnGe46mhbYQ9xtzOeQ0FSs=; b=YjO3G8IrzpWjChusFRLn5CLp+3D7Fl/QyUHp914lNPk7lin2B/op/mCa9QcKQqvdu1 wWJvssazg42r2TUEjDGoDDBWyHHriVk0byAQZyegKIi7rRCa5NiygVJ3JPj7p2HWZCYh B9JWtC4GOZyeU86W1OEh6fO9JLGpBAY9CTLCgdYVNg7brfUyj2Sh9lPGBE17QIgOUNbC G32AReKecuEiFmf0+JxiYm2O7r1XrrbV+sBbDSZXhGoPgrP9S7I8ep/Im9zV34xAM4/L k4akBnA2q/iN1gBVSfs3srExOfQ78+k4HGl5qJpZdZbiqBIm2uXG1ccaQ6EIKQWNCL2g 3ITw== MIME-Version: 1.0 X-Received: by 10.52.76.73 with SMTP id i9mr10822078vdw.25.1358574011263; Fri, 18 Jan 2013 21:40:11 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 18 Jan 2013 21:40:11 -0800 (PST) In-Reply-To: <006701cdf21e$f9679bf0$ec36d3d0$@ndzh.com> References: <006701cdf21e$f9679bf0$ec36d3d0$@ndzh.com> Date: Sat, 19 Jan 2013 06:40:11 +0100 Message-ID: From: Abdussalam Baryun To: Susan Hares Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Technical issue #7 - AODV can loose route replies - warning longer post X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 05:40:14 -0000 Hi Sue, some answers and comments in line; > Glabbeek et al. (2013) Comments: AODV can lose route replies ( > > http://www.ietf.org/mail-archive/web/manet/current/msg05702.html). I checked the pointer but in AODVv2 is does not miss replies, as in section 6.1 and it forwards messages not like msg05702 suggested. > > The reason is that route replies are only forwarded by an intermediate no= de > when the node updates its routing table. This problem has partly been > solved in DYMO and LOADng by increasing sequence numbers when initiating = a > route reply. However, a careful analysis shows that replies can still be > lost; yielding again non-optimal routes or route discovery failures. > Namely, > if one route reply overtakes another, i.e., a newer reply reaches a node > earlier than an older one, then the older route reply is dropped [4]. It is solved in DYMO but not sure with LOADng (still I will investigate that), the seqNum is for freshing routes but the routers don't update only if necessary, > > A solution consists of intermediate nodes always forwarding route replie= s. > Surely, forwarding (unicasting) replies increases the number of messages = in > the network. But, (a) route discovery is more likely and (b) re-sending a > route request to establish a route would yield another broadcast cycle, > which is much more expensive w.r.t. network load. not always forward replies, but only for the requesters that the router has a route to, otherwise disregard. > > Charlie=92s comments: I guess you mean that the two RREPs under discussi= on > were going towards two distinct Originating Nodes. Otherwise, it would b= e > good for the older RREP to be dropped. For the case of two distinct > Originating Nodes, the behavior is a protocol error that needs to be fixe= d. > "Always forwarding" RREPs is one alternative, and certainly preferable to= a > new Route Discovery cycle in the network. The behavior is ok, please see my post below: http://www.ietf.org/mail-archive/web/manet/current/msg14730.html > > > I am confident that there is a better solution, and I will work on findin= g > and specifying it. Always there are better solutions for MANET > > Sue=92s Comments/questions > 2. Comment: RREP to going to two originating nodes IMHO seems to be= a > problem that is basic. Charlie says ADOV-25 has it fixed. LoadNG always > sends the RREP back to the same originator. > Yes > 4. Question: is there ever a connectivity problem with if the older > route being dropped? Can you provide the scenario? > don't think there is problem as long is reconnected to new route > > 5. What is the cost of intermediate nodes always forwarding route > replies? the problem is cost of RREQ, but RREP cost depend on number of demands and of nodes in network. > > The topologies do matter in DV. Have these algorithms been run multiple > topologies. > should be done, but also with different subnets and technologies, > > Again =96 if this has been discussed on list, or in presentations, or pap= ers I am trying to update a draft [AB] on this issues, because I beleive that subnet technologies and topology has influence on the algorithm, I used your paper in my draft as well, but still searching for more to update. The WG discussed this issue in 2012 but most just want to consider dynamic topology. > =96 > just let me know. I=92ll go look it up, and come back with better questi= ons. > Yes I will send you my updates on these issues when available, please do also, or if you have advise for my draft, [AB] http://tools.ietf.org/html/draft-baryun-manet-technology-00 Best Regards Abdussalam Baryun University of Glamorgan, UK From jvasseur@cisco.com Sat Jan 19 03:10:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575EE21F84C9 for ; Sat, 19 Jan 2013 03:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiQT4wvZHOwJ for ; Sat, 19 Jan 2013 03:10:04 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0AB21F84BC for ; Sat, 19 Jan 2013 03:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4628; q=dns/txt; s=iport; t=1358593804; x=1359803404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cHVlW0iHXWxDvsv37QiFlZ/J/vc49wHxkDjGpkM9CLE=; b=VGAUzvp9Snsb0WXj7yHZCzzkHSufMaKwx9Ck58FyO73fok3E9zjbiNXM PLECelYi/uj6tvL1K3RpcHWC2HPa8UpwHZmMBpMYfGGgtsqKcy8dUjwo1 PeCvb1BFi000/TJR29wq2ExWCMyrl6wewyJkmlyPSRkmj1eHwInI26ywH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKF++lCtJXG//2dsb2JhbABEvj4Wc4IeAQEBAwEBAQFrCwUHBAIBCBEEAQEBCh0HIQYLFAkIAgQOBQiHfwMJBgyzIA2IYowJhE9hA4gsjAqCcoobhRKCdYIk X-IronPort-AV: E=Sophos;i="4.84,498,1355097600"; d="scan'208";a="164847112" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jan 2013 11:10:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0JBA2dZ026234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jan 2013 11:10:02 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.64]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sat, 19 Jan 2013 05:10:02 -0600 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: [manet] Router's Implemetation and Running Code Thread-Index: AQHN9jWGToPfHGQo4kWwvKUj/t5aqg== Date: Sat, 19 Jan 2013 11:10:01 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> In-Reply-To: <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7ACA3B047B164C4EACACB91F80A98A7E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 11:10:05 -0000 That being said I'd rather now focus on the new WG I-D AODVv2 On Jan 17, 2013, at 9:18 AM, Thomas Heide Clausen wrote: > Abdussalam, >=20 > This is really incredible; did you actually _read_ the Interoperability r= eport? Please do so, before jumping to assumptions. >=20 > For each interoperability event, there is a section "Participating Implem= entations". Here's an example, snipped from the draft from the _first_ inte= rop test (when there were just 3 implementations - the latter tests had 4).= It is explicitly mentioned that in that test, there's one Java implementat= ion, one C implementation for an embedded platform and one C++ implementati= on for MacOS. >=20 >> 4.3. Participating Implementations >>=20 >>=20 >> The following implementations were used to perform the >> interoperability tests this section, listed alphabetically: >>=20 >> Ecole Polytechnique: "LIX" - This implementation was jointly >> developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and >> Thomas Clausen of Ecole Ploytechnique's networking team. It >> consists of approximately 6000 lines of JAVA code running in a Mac >> OS environment. It supports RREQ, RREP, RREP-ACK and RERR >> generation, processing, forwarding and transmission. >>=20 >> Hitachi YRL 1: "Hitachi 1" - This implementation was fully developed >> by Yuichi Igarashi of Hitachi YRL. It consists of 1589 lines of C >> code running in the Hitachi proprietary micro OS environment >> embedded in a 16MHz H8 micro processor. It supports RREQ, RREP, >> RREP-ACK and RERR generation, processing, forwarding and >> transmission. >>=20 >> Hitachi YRL 2: "Hitachi 2" - This implementation was jointly >> developed by Nobukatsu Inomata of Hitachi ULSI Systems and Yoko >> Morii of Hitachi YRL. It consists of 1987 lines of C++ code >> running in a Mac OS environment. It supports RREQ, RREP, RREP-ACK >> generation, processing, forwarding and transmission, and RERR >> processing. >=20 >=20 > Thomas >=20 >=20 > On Jan 17, 2013, at 08:57 , Abdussalam Baryun wrote: >=20 >> Thanks Sue for your input, >>=20 >> That was my understanding when read inteop-loadng draft before, just >> to add to you text *four different devices*, but will read again when >> I can. The authors confirmed that they documented it correctly, >>=20 >> AB >>=20 >> On 1/17/13, Susan Hares wrote: >>> AB and Henning: >>>=20 >>> Let me confirm - these results are one implementation ported to four >>> devices? >>>=20 >>> Sue >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of >>> Abdussalam Baryun >>> Sent: Tuesday, January 15, 2013 6:35 AM >>> To: Henning Rogge >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Router's Implemetation and Running Code >>>=20 >>> Hi Henning, >>>=20 >>> thanks alot, but I think the tests reported by the doc is only for one >>> implementation, not all 4 LOADng implementations, however, I will conta= ct >>> the authors of the doc, thanks, >>>=20 >>> AB >>>=20 >>> On 1/15/13, Henning Rogge wrote: >>>> On 01/15/2013 12:14 PM, Abdussalam Baryun wrote: >>>>> As you agree with RFC2026, I can understand you mean that the 4 >>>>> implementation you refered to previously are interoperable, please >>>>> confirm, and that they may work together, >>>>=20 >>>> Maybe this will answer your question? I think this document was >>>> already mentioned on this list. >>>>=20 >>>> http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-re >>>> port-04 >>>>=20 >>>> Henning Rogge >>>>=20 >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, >>>> Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sat Jan 19 05:14:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5A121F85A3 for ; Sat, 19 Jan 2013 05:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gfTV4pujM3V for ; Sat, 19 Jan 2013 05:14:55 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id EECBC21F84CC for ; Sat, 19 Jan 2013 05:14:54 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so3389543vbb.10 for ; Sat, 19 Jan 2013 05:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=rSTL7+7l6IycVhBRElpsjbWzCXefDCbCnxtBfhIv8UI=; b=HdM3b7PP4xaS2F4+z6/eo4wQLvvXKgKxPRMZ9vWM3vmQYAXm1XysCgTJmjqfccuVa5 zRU3DtBzzPHxSw5kS+XA5nFbibSx2YC1ORXKJFKZ8+W6ilqT4MrmqPpdLln8k5FZ2ELp VYsJbEnJMOJk7Z+eEKkZCdoeZHD2oWeZ555zNeIqc2HZvTpCEqTnXVPHCv6I4rNxDHSF fNaYR4Gh63ybKKfQp/9ArOJoh0W62Ukqo6OQ9qJ1V2mki5WXYg5OQLqL3jWGEyt3/Mow tzCvSbtMdE5t51ojFojp2bMeEmLcUoo4BySi275PQAPeLz8M+oOE7uz0hPddSjp2FDZv Mbsw== MIME-Version: 1.0 X-Received: by 10.220.218.197 with SMTP id hr5mr13061742vcb.8.1358601294271; Sat, 19 Jan 2013 05:14:54 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sat, 19 Jan 2013 05:14:53 -0800 (PST) In-Reply-To: <50AB4E2D.8080500@fkie.fraunhofer.de> References: <50AB4E2D.8080500@fkie.fraunhofer.de> Date: Sat, 19 Jan 2013 14:14:53 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 13:14:56 -0000 ++++++++++++++ First Reminder +++++++++++++++++ Hi Authors of DLEP, and All I wish to see your reply/respond in this thread about the proposal, please note that it has been now 3 months delay with no response from the editor or authors. Your respond is required in my opinion for progress, please advise, *Please note that the DLEP submission milestone is March 2013* Regards Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++ On 11/20/12, Henning Rogge wrote: > Hi, > > as discussed during the IETF, here a few thoughts about additional > metric TLVs. > > I think that including a larger set of metric TLVs (like Relative Link > Quality, Current/Maximum Datarate, ...) is a good thing, because it > allows radio/router implementors to choose from a larger set of > standardized TLVs, which increase the chance of interoperability between > the products. > > There are two kinds of metric TLVs, one of them contain information > about the network the radio is attached to and one of them contain > information about the link of the radio to a target. > > Network specific metric TLVs > ---------------------------- > > * network-id > > A binary identifier of the network the radio is attached to (1-16 octets > binary) > > * network-description > > A text identifier of the network the radio is attached to (1-80 octects > ascii) > > * supported-rates > > An array of datarates supported by the radio on the current network > (array of 8 octet values in bit/s) > > * last-active > > Time since the last data was sent or received over the radio (4 octet > value in milliseconds) > > * frequency > > Mid-Frequency of the current radio channel (8 octet value in Hz) > > * bandwidth > > Amount of spectrum a radio channel uses (8 octet value in Hz) > > > Neighbor specific metric TLVs > ----------------------------- > > * maximum-datarate > > This one already exists in DLEP, but doesn't report both incoming and > outgoing maximum link speed, which could be different. > > * current-datarate > > Same as maximum datarate, incoming and outgoing speed can be different. > > * traffic > > Amount of bytes sent and received with the neighbor (8+8 octet value) > > * packets > > Amount of IP packet sent and received with the neighbor (8+8 octet value) > > * frames > > Amount of layer-2 frames sent and received with the neighbor (8+8 octet > value) > > * tx-retries > > Number of linklayer retransmissions for IP packets (8 octet value) > > * tx-fails > > Number of failed linklayer transmissions > > * last-active > > Time since the last data was sent or received with this neighbor (4 > octet value in milliseconds) > > ---------------------- > > The traffic and packet TLVs become important when you have multiple > routers of hosts attached to a DLEP capable radio, because they cannot > track the traffic on their local interface anymore. > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From trac+manet@trac.tools.ietf.org Sat Jan 19 13:09:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC721F854F for ; Sat, 19 Jan 2013 13:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znCwS2kVif8g for ; Sat, 19 Jan 2013 13:09:55 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4409221F86FB for ; Sat, 19 Jan 2013 13:09:55 -0800 (PST) Received: from localhost ([127.0.0.1]:45086 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Twffm-0006hA-2J; Sat, 19 Jan 2013 22:09:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sat, 19 Jan 2013 21:09:54 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/14 Message-ID: <066.50c2631dbd61de8502cd1e8fc6568412@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #14: A Proposal of Metric TLVs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:09:55 -0000 #14: A Proposal of Metric TLVs I am trying for the first time this tool, however, Please check the proposal in; http://www.ietf.org/mail-archive/web/manet/current/msg14733.html Best Regards Abdussalam -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: Component: dlep | Version: Severity: Active WG Document | Keywords: Metric TLVs For DLEP ----------------------------------------+---------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Sat Jan 19 13:20:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A6C21F8750 for ; Sat, 19 Jan 2013 13:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU92D1TpQEEE for ; Sat, 19 Jan 2013 13:20:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F244E21F874C for ; Sat, 19 Jan 2013 13:20:41 -0800 (PST) Received: from localhost ([127.0.0.1]:45695 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TwfqC-0008Li-FR; Sat, 19 Jan 2013 22:20:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sat, 19 Jan 2013 21:20:40 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/manet/trac/ticket/1#comment:1 Message-ID: <076.aeda4b8970dc4babcf584eca591686c9@trac.tools.ietf.org> References: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #1: Discussion about naming for the IETF reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:20:43 -0000 #1: Discussion about naming for the IETF reactive protocol Comment (by abdussalambaryun@gmail.com): I agree with the name as AODVv2 is suitable for the new reactive protocol because it depends on the AODVv1. As we new versions of protocols like IP. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: task | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: reactive naming | -----------------------------------+------------------------------ Ticket URL: manet From trac+manet@trac.tools.ietf.org Sat Jan 19 13:27:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4121F86FD for ; Sat, 19 Jan 2013 13:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow6LvzKK2Egf for ; Sat, 19 Jan 2013 13:27:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8A31D21F86E7 for ; Sat, 19 Jan 2013 13:27:24 -0800 (PST) Received: from localhost ([127.0.0.1]:46164 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Twfwe-0005aO-5R; Sat, 19 Jan 2013 22:27:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sat, 19 Jan 2013 21:27:20 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/9#comment:1 Message-ID: <076.52442cdbde1e4756a95fb455111cef29@trac.tools.ietf.org> References: <061.a0055255c275fede343be9cc794f90e9@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <061.a0055255c275fede343be9cc794f90e9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #9: Reserved value for AODVv2 SeqNum -- is it necessary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:27:25 -0000 #9: Reserved value for AODVv2 SeqNum -- is it necessary Comment (by abdussalambaryun@gmail.com): Replying to [ticket:9 charliep@…]: > > > Whether or not to specify a reserved !SeqNum is not a trivial issue. > With recent revisions, it is now feasible to conduct a Route Discovery > cycle (RREQ / RREP) without need for indicating that a !SeqNum is > invalid, and there do not seem to be any other instances in the current > specification where a !SeqNum has to be reported as invalid. It will be not necessary but may be used by router's processing checks, > > If there is to be a reserved value for !SeqNum, it seems that 0 (zero) > is a good choice, so that rollover skips from 65535 to 1 bypassing the > reserved value of zero. > I agree -- ----------------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: Sequence number management | ----------------------------------------+------------------------------ Ticket URL: manet From trac+manet@trac.tools.ietf.org Sat Jan 19 13:32:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E2921F857D for ; Sat, 19 Jan 2013 13:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbSNFXDOa1bg for ; Sat, 19 Jan 2013 13:32:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C4F5F21F8793 for ; Sat, 19 Jan 2013 13:32:40 -0800 (PST) Received: from localhost ([127.0.0.1]:46425 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Twg1m-0003Df-Nq; Sat, 19 Jan 2013 22:32:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sat, 19 Jan 2013 21:32:38 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/11#comment:1 Message-ID: <076.09b318d2e67bd2c833c6d8f96b68299f@trac.tools.ietf.org> References: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #11: Error: failure of delivery to single host can invalidate route to an entire network X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:32:42 -0000 #11: Error: failure of delivery to single host can invalidate route to an entire network Comment (by abdussalambaryun@gmail.com): Replying to [ticket:11 charliep@…]: the intermediate node (i) should be noticed that a next hop router is lost by receiving RERR, the RERR mentions what is lost. So if the host destination is lost only the source or last (i) in the route should be interested not any (i), others should ignore. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: RERR, subnet route | -----------------------------------+------------------------------ Ticket URL: manet From trac+manet@trac.tools.ietf.org Sat Jan 19 16:11:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B91421F86D3 for ; Sat, 19 Jan 2013 16:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGIw00ejTJH1 for ; Sat, 19 Jan 2013 16:11:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F09C121F8658 for ; Sat, 19 Jan 2013 16:11:26 -0800 (PST) Received: from localhost ([127.0.0.1]:58400 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TwiVR-0003JX-EZ; Sun, 20 Jan 2013 01:11:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sun, 20 Jan 2013 00:11:25 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/15 Message-ID: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #15: Reactive Design Approach X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 00:11:33 -0000 #15: Reactive Design Approach There is a problem that reactive work better in some application scenarios and proactive work better in other application scenarios, but both are important for MANETs in general. However, there are some application scenarios where the hybrid routing is the best choice for the MANET. Another problem is that generated routing information are different in reactive and proactive, so it will be reasonable that there may be different best formatting, which needs an answer/discuss. The design approach to start with the messaging format before the completion of designing both proactive and reactive separate standards can't be the right approach for designing general purpose protocols. That may be a good approach for manet hybrid routing that includes both reactive and proactive routing functions. However, there is no prove that similar message formatting will give better performance for two separate protocols for different scenarios. I suggest the WG reactive protocol modified without thinking of a hybrid or proactive routing, but just the reactive. Also I suggest we don't think about gateway issues as leave it in separate draft. -- ----------------------------------------+------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: Design Approach ----------------------------------------+------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Sat Jan 19 18:05:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C321F873C for ; Sat, 19 Jan 2013 18:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npyJ9EPTJIBr for ; Sat, 19 Jan 2013 18:05:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA321F8449 for ; Sat, 19 Jan 2013 17:17:44 -0800 (PST) Received: from localhost ([127.0.0.1]:34084 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TwjTH-0008VQ-ST; Sun, 20 Jan 2013 02:13:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sun, 20 Jan 2013 01:13:15 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/manet/trac/ticket/16 Message-ID: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #16: The Reactive Protocol Duplicate Suppression Table X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 02:05:42 -0000 #16: The Reactive Protocol Duplicate Suppression Table I agree with the proposed to add RREPs in table as RREQ for suppression as below message, however, will need to discuss if there are side affects http://www.ietf.org/mail-archive/web/manet/current/msg14472.html -- ----------------------------------------+--------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: Message suppression ----------------------------------------+--------------------------------- Ticket URL: manet From henning.rogge@fkie.fraunhofer.de Sun Jan 20 23:08:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF021F8826 for ; Sun, 20 Jan 2013 23:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyvrCdRz7Eqp for ; Sun, 20 Jan 2013 23:08:49 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFF321F87E1 for ; Sun, 20 Jan 2013 23:08:48 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxBUs-0005Yn-MC for manet@ietf.org; Mon, 21 Jan 2013 08:08:46 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxBUs-00081B-JY for manet@ietf.org; Mon, 21 Jan 2013 08:08:46 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jan 2013 08:08:46 +0100 Message-ID: <50FCE97D.3080501@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 08:08:45 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080203020102010507060706" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16537/Mon Jan 21 06:43:57 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d6e894cdea8d3a22ba2bc442380ed802 Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 07:08:50 -0000 --------------ms080203020102010507060706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/19/2013 12:10 PM, JP Vasseur (jvasseur) wrote: > That being said I'd rather now focus on the new WG I-D AODVv2 We know thats your opinion... Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080203020102010507060706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjEwNzA4NDVaMCMGCSqGSIb3DQEJBDEWBBT2EAhmNHNtfCtVe6DOfVVwiBhOEDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAc/ghfjLbfRB38AoGzCG4MJUPIHgUBX9td56JLHBxHQZK juZB9ihzo5Ar+vWT8T6wMPjIawCwUXIB6oSxuUhEHcUfCl8F+YOXDAtJ3wcDjGtbZSni7SQ/ 8OTYEgYpdD2urxE8z6NKhMW/IOil/aj3HMZLZzqrfGCTWZ6Z1elF/fp/hQi+O6dm6MkEmaqN LnqCYskrKT2HMpFBC+A5yMetH4qVCJpmCN4aWrz/rS8SUkhdpS/ODiiHmlrwr0CE9ttw2ln2 iq5Q6v2xBQpY482408gwV4uQeFhgKKiWdYUDm8GpZlnDoiBGB4yniB6em3fPDHYz6c67yMDf 3BLSBuVlHQAAAAAAAA== --------------ms080203020102010507060706-- From abdussalambaryun@gmail.com Mon Jan 21 03:47:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA60421F86AE for ; Mon, 21 Jan 2013 03:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeGuXUvzlX3g for ; Mon, 21 Jan 2013 03:47:13 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6438E21F86A9 for ; Mon, 21 Jan 2013 03:47:13 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id v40so2667566dad.22 for ; Mon, 21 Jan 2013 03:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6OwoKsRoGWMcu4QUIjLphZ5Kd/MMDmy117EOL9ImaEA=; b=UUZgQn6aRQ++F0rxcTkpJHZXfq2VcCiUXwDp4zuPO8EycRQKMwG+KZiQqmmLSmRzyl C3EcPwY/csToZX+SknnPJdfIQc2pWdB8gFOChRnvHTbR3xMRicadrAZ+gPGv46pw/rDN KEPrAQcp1/4uOQOKCeVs5KF0Rp6FVc6pYPBJjZC2WiHMpsE6YDgIoq/mPMh0WvjCP9j7 nlSD3pOJ8yzsdFS7GDbr5zkK2nsbO49gP57hH8szcqYPwmDyprrUCoNYTyDBKK9pZ8CE DndAQolVxl2vw0pJHJ6uuTJ3Qv0/xejXgM4i+pvCyDrID+ZHgY9/5VLfxCbITyD+8pd4 Dp5w== MIME-Version: 1.0 X-Received: by 10.69.0.40 with SMTP id av8mr48053944pbd.117.1358768833068; Mon, 21 Jan 2013 03:47:13 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 03:47:12 -0800 (PST) In-Reply-To: <50FCE97D.3080501@fkie.fraunhofer.de> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 12:47:12 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 11:47:13 -0000 Hi Henning, The interesting point in these LOADng-implemented codes that they were implemented differently and then tested together and reported in IETF, which I think is rare from companies/organisations to do that. IMHO, I think the test/report of interoperability of different and independent implementations is very important for router users and the market. I thank all who explained for me this including you, because I don't think it was discussed/understood before, Best Regards, AB From henning.rogge@fkie.fraunhofer.de Mon Jan 21 03:58:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8A221F86C9 for ; Mon, 21 Jan 2013 03:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idm+npwu73Bv for ; Mon, 21 Jan 2013 03:58:34 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 66B2621F8620 for ; Mon, 21 Jan 2013 03:58:27 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxG1C-0001fV-DQ; Mon, 21 Jan 2013 12:58:26 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxG1C-0007eh-Ah; Mon, 21 Jan 2013 12:58:26 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jan 2013 12:58:25 +0100 Message-ID: <50FD2D5C.6010902@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 12:58:20 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000008000706080006000805" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16537/Mon Jan 21 06:43:57 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 11:58:35 -0000 --------------ms000008000706080006000805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/21/2013 12:47 PM, Abdussalam Baryun wrote: > Hi Henning, > > The interesting point in these LOADng-implemented codes that they were > implemented differently and then tested together and reported in IETF, > which I think is rare from companies/organisations to do that. IMHO, I > think the test/report of interoperability of different and independent > implementations is very important for router users and the market. I > thank all who explained for me this including you, because I don't > think it was discussed/understood before, Yes, it is... at the moment I am not even sure there is a single DYMO-25 compatible=20 implementation. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000008000706080006000805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjExMTU4MjRaMCMGCSqGSIb3DQEJBDEWBBRyZTnhHiGnXR5HzH84G708L8n74zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAj3TVQCyZdQeQwDd1yv1BKTy6aPSPmZ8kuy7+EmmutWaQ Q3rcy3Y+K7W1TZSygEYMyle+FsZZqTspD4Q/4rIxxZPqCHFQcZY83YRKXHm4tfiZv1QRezTt xCEzyzq28RohcYAfGtDVp3Une5hHiWS1p+uUQyU9QJG0MrXrvAUFeLJsN3ySm0qT6bkxFMMD fooj9ZVLSuov1E3Ej+e35779/wIwBoGaxenz+apHk1lSYRbNcDl91Fequps5GCHcvRFvorqU o/LkOMO7b+KsoZFyg5KtQmDhkM0Z5W8eXP5onNp+9SniorcfuAQ2350W3nKP6CKUP9Mko6VS jKlnkI+5gQAAAAAAAA== --------------ms000008000706080006000805-- From abdussalambaryun@gmail.com Mon Jan 21 05:15:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96721F871C for ; Mon, 21 Jan 2013 05:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um39bHx2ByDO for ; Mon, 21 Jan 2013 05:15:31 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 064F121F84C5 for ; Mon, 21 Jan 2013 05:15:24 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz10so3411162pad.23 for ; Mon, 21 Jan 2013 05:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=0JXYIr9/kO4RlHkanFSikwoN0SQZONv87c8OqTJllc0=; b=l4zo7N9Yye9j5LsHsta8Sg4xpyM0qtciYi2o5I+jqgNZCv0FxUnIKXeYkEtPMIzwPE 9SehUm9acuNk8xHO1C6d3XN5BYuvuIjs4L/NHHyR+lIJzohUuDbLDOKdvvqKmZXWtPdw 7MTwnpKmkFrmttnIiBYJqrcBcgseBkbJO7Oqe9c7T6eypEycbaQenZPm2BsmDXImVk3c Bfx8vuLkYBqJ5KxKH0PaiGBzQ4hqhori/oLTxOpkknM9t6d0zvI/ykWEAH7TvMZzBucu 4pSoNsbAXv7MhFTIyIM68R1Uh3ckR+xYBDRjsbbj+Gu747PSP91OZfQUIcrkSUVvSg9R AXeA== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr29512902pbc.20.1358774124768; Mon, 21 Jan 2013 05:15:24 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 05:15:24 -0800 (PST) In-Reply-To: <50FD2D5C.6010902@fkie.fraunhofer.de> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 14:15:24 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 13:15:31 -0000 Hi Henning, Regarding the interop-testing, was there tests for interoperability for OLSRv1 or OLSRv2, as it is our completed standard. I am wondering if the Funkfeuer and Freifunk routers implemented differently and independetly, if yes it will be interesting to know if that test was done. Please advise, AB On 1/21/13, Henning Rogge wrote: > On 01/21/2013 12:47 PM, Abdussalam Baryun wrote: >> Hi Henning, >> >> The interesting point in these LOADng-implemented codes that they were >> implemented differently and then tested together and reported in IETF, >> which I think is rare from companies/organisations to do that. IMHO, I >> think the test/report of interoperability of different and independent >> implementations is very important for router users and the market. I >> thank all who explained for me this including you, because I don't >> think it was discussed/understood before, > > Yes, it is... > > at the moment I am not even sure there is a single DYMO-25 compatible > implementation. > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From thomas@thomasclausen.org Mon Jan 21 05:18:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB5D21F8735 for ; Mon, 21 Jan 2013 05:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbCaRaEtm4cs for ; Mon, 21 Jan 2013 05:18:57 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D426C21F84A1 for ; Mon, 21 Jan 2013 05:18:57 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id AA100A6721 for ; Mon, 21 Jan 2013 05:18:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8014D1BD0823; Mon, 21 Jan 2013 05:18:57 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from 201-27.eduroam.saclay.inria.fr (nat-invites.saclay.inria.fr [195.83.213.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C25C41BD0820; Mon, 21 Jan 2013 05:18:56 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: Date: Mon, 21 Jan 2013 14:18:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F3A7504-60FC-4421-AFBE-156758B07E50@thomasclausen.org> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 13:18:59 -0000 Try the link below: http://lmgtfy.com/?q=3DOLSR+Interop On Jan 21, 2013, at 14:15 , Abdussalam Baryun = wrote: > Hi Henning, >=20 > Regarding the interop-testing, was there tests for interoperability > for OLSRv1 or OLSRv2, as it is our completed standard. I am wondering > if the Funkfeuer and Freifunk routers implemented differently and > independetly, if yes it will be interesting to know if that test was > done. Please advise, >=20 > AB >=20 > On 1/21/13, Henning Rogge wrote: >> On 01/21/2013 12:47 PM, Abdussalam Baryun wrote: >>> Hi Henning, >>>=20 >>> The interesting point in these LOADng-implemented codes that they = were >>> implemented differently and then tested together and reported in = IETF, >>> which I think is rare from companies/organisations to do that. IMHO, = I >>> think the test/report of interoperability of different and = independent >>> implementations is very important for router users and the market. I >>> thank all who explained for me this including you, because I don't >>> think it was discussed/understood before, >>=20 >> Yes, it is... >>=20 >> at the moment I am not even sure there is a single DYMO-25 compatible >> implementation. >>=20 >> Henning Rogge >>=20 >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Mon Jan 21 06:11:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB521F8754 for ; Mon, 21 Jan 2013 06:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRqP3iU64UoA for ; Mon, 21 Jan 2013 06:11:07 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63421F85AB for ; Mon, 21 Jan 2013 06:11:07 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id un15so3360087pbc.36 for ; Mon, 21 Jan 2013 06:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BPlsigNsSmonfTYqNWpEjjD8VSd7sADpCWm28nkzp4I=; b=Gr/wzn33kAiHnbGFpDIzWSVkewHjxRtwFuOtxL0JsC/xy9tuSB2ei7CKIgBgn5h51R HSG1jDg5iJFhgFn7n2/AqOgxDHD8PhAPfFqzRO50HK2CWnFA9jkcXM8wj8bxWMh6awVu oriuKGM40snPB533YXpihdxP8QLJsn/tBGduj5xg1hYRMUAAR6nwXlkgHLlwquQ+PjA0 Pga0azARlzMf8HwtCJDGQAIWA+KLiR26CrceIeYfx9hCqAjKbUP2wVSoTDaEWICOvPZ4 gPRDLQjtFO/KhCjUfboU7EsFW2H/wzjuJKZ4SNDrINxO9Z9EVQpPfjaOJ1J0Si0po5ZD gF1g== MIME-Version: 1.0 X-Received: by 10.66.78.100 with SMTP id a4mr47611595pax.4.1358777467322; Mon, 21 Jan 2013 06:11:07 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 06:11:07 -0800 (PST) In-Reply-To: <5F3A7504-60FC-4421-AFBE-156758B07E50@thomasclausen.org> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> <5F3A7504-60FC-4421-AFBE-156758B07E50@thomasclausen.org> Date: Mon, 21 Jan 2013 15:11:07 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:11:08 -0000 Hi Thomas, and Henning, ok I found tests reports for OLSRv1, but what about OLSRv2, just found workshops but did not find results/report. Could you give me a point to these reports, Thanking you, AB On 1/21/13, Thomas Heide Clausen wrote: > Try the link below: > > http://lmgtfy.com/?q=3DOLSR+Interop > > On Jan 21, 2013, at 14:15 , Abdussalam Baryun > wrote: > >> Hi Henning, >> >> Regarding the interop-testing, was there tests for interoperability >> for OLSRv1 or OLSRv2, as it is our completed standard. I am wondering >> if the Funkfeuer and Freifunk routers implemented differently and >> independetly, if yes it will be interesting to know if that test was >> done. Please advise, >> >> AB >> >> On 1/21/13, Henning Rogge wrote: >>> On 01/21/2013 12:47 PM, Abdussalam Baryun wrote: >>>> Hi Henning, >>>> >>>> The interesting point in these LOADng-implemented codes that they were >>>> implemented differently and then tested together and reported in IETF, >>>> which I think is rare from companies/organisations to do that. IMHO, I >>>> think the test/report of interoperability of different and independent >>>> implementations is very important for router users and the market. I >>>> thank all who explained for me this including you, because I don't >>>> think it was discussed/understood before, >>> >>> Yes, it is... >>> >>> at the moment I am not even sure there is a single DYMO-25 compatible >>> implementation. >>> >>> Henning Rogge >>> >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Mon Jan 21 06:34:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DB721F881D for ; Mon, 21 Jan 2013 06:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUrcQXV5Grhq for ; Mon, 21 Jan 2013 06:34:33 -0800 (PST) Received: from mail-da0-f51.google.com (mail-da0-f51.google.com [209.85.210.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2483521F85C0 for ; Mon, 21 Jan 2013 06:34:33 -0800 (PST) Received: by mail-da0-f51.google.com with SMTP id i30so2753005dad.10 for ; Mon, 21 Jan 2013 06:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=hqQFT9wts7FXerKqDGsZJ7YAWIcePPoTb7rIo7jEw+E=; b=CZZD8XMa9Uz6jeaFZnSQgoknuTijiH7NN+rEAro2g4VPSrMtwV5gqbAAnzoB4yoTlH F9th6RrJ2QfsSYkEzKql+2VXeQFYudHEaMfV+KwRrGdVhWxLfSYv5FyBi0hnlsoW+p6/ J8L51FScEtX+4SBM6DteGajmkqsrg/CwhejgcWLh5lc7Zd260hHBrCzznw8dxjG0uaMW qB11bQJSqj7R8tCGBMn9o29JV4kvT9yLNVeHEcNqzaUJx6vTBO2svAFxz2SyA+LzS2Mi 9J/6rTk7VO4eykKNHhh6bie+BBq6RFwdBKnyed2aZSrUyLZFQq8f9UevxRfvHCRzPPse WLfA== MIME-Version: 1.0 X-Received: by 10.66.72.226 with SMTP id g2mr47337411pav.67.1358778868286; Mon, 21 Jan 2013 06:34:28 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 06:34:27 -0800 (PST) In-Reply-To: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 15:34:27 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:34:34 -0000 Hi Henning The below draft explains how OLSRv2 is used in funkfeuer, but not sure of interoperability with other routers; please advise, http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 AB On 1/21/13, Abdussalam Baryun wrote: > Hi Henning, > > Regarding the interop-testing, was there tests for interoperability > for OLSRv1 or OLSRv2, as it is our completed standard. I am wondering > if the Funkfeuer and Freifunk routers implemented differently and > independetly, if yes it will be interesting to know if that test was > done. Please advise, > > AB > > On 1/21/13, Henning Rogge wrote: >> On 01/21/2013 12:47 PM, Abdussalam Baryun wrote: >>> Hi Henning, >>> >>> The interesting point in these LOADng-implemented codes that they were >>> implemented differently and then tested together and reported in IETF, >>> which I think is rare from companies/organisations to do that. IMHO, I >>> think the test/report of interoperability of different and independent >>> implementations is very important for router users and the market. I >>> thank all who explained for me this including you, because I don't >>> think it was discussed/understood before, >> >> Yes, it is... >> >> at the moment I am not even sure there is a single DYMO-25 compatible >> implementation. >> >> Henning Rogge >> >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> > From henning.rogge@fkie.fraunhofer.de Mon Jan 21 06:36:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED421F84F9 for ; Mon, 21 Jan 2013 06:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0U89PHPs+QI for ; Mon, 21 Jan 2013 06:36:28 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2322B21F84F5 for ; Mon, 21 Jan 2013 06:36:28 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxIU7-0005hN-Gf; Mon, 21 Jan 2013 15:36:27 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxIU7-00046J-Dy; Mon, 21 Jan 2013 15:36:27 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jan 2013 15:36:27 +0100 Message-ID: <50FD526A.6040602@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 15:36:26 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050703030406000006040605" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16539/Mon Jan 21 14:42:07 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e2b21d81e24158e5c3d75098b3c9c024 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:36:29 -0000 --------------ms050703030406000006040605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/21/2013 02:15 PM, Abdussalam Baryun wrote: > Hi Henning, > > Regarding the interop-testing, was there tests for interoperability > for OLSRv1 or OLSRv2, as it is our completed standard. I think there were quite a few OLSRv1 interop tests done in the past. > I am wondering > if the Funkfeuer and Freifunk routers implemented differently and > independetly, if yes it will be interesting to know if that test was > done. Please advise, Freifunk/Funkfeuer (and most of the Wireless Community Mesh Networks)=20 use the Olsr.org OLSR implementation with the proprietary ETX metric=20 implementation. The problem is that without a metric extension, most routing protocols=20 are nearly unusable in a MANET. There are two "well known" OLSRv1=20 implementation with ETX, one is the Olsr.org implementation and the=20 other one is from the NRL. Both use their own way to encode the metric, so they are not compatible=20 in ETX mode. OLSRv2 implementations are still "work in progress", but I did some=20 preliminary interop tests of NHDP between my own and the NRL=20 implementation and plan to extend this this year (as soon as I stop=20 finding bugs/problems in my own NHDP implementation ^^). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050703030406000006040605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjExNDM2MjZaMCMGCSqGSIb3DQEJBDEWBBRLaOPiEjCakpw0wqX4v1cqiWE7+TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAOlNlagdS/rndkEY/NhnNC2OuJa7oh/PcdZ0JWlhA6CQX xdRF/rs8bMjo5GfAUX/aodP3IwG3Git/NRgqG1dj7HxqD2kbHUV4AOkzFOYFTvM+5XHz4TP9 z99PiwtBEnFwiVCAKxgK51ZbMJrlcrZemZ953IAR1zOkBUyoTfFvSRsXs8m78sewu5sP4s6x kvYzNv8OYk/5+uQBdadXFryWumpYy6qVTxCZ1/5I/aoJXRDUePYgR0cpQNXC3JfxsIHw2T+g YHLoPTGK1o1ahI/5YBltHCbqaqxK5TiXv9PUyS4r500hJg6nDXS6YkUCrbxSE2SEPSg+HlCg o6oiO06JewAAAAAAAA== --------------ms050703030406000006040605-- From henning.rogge@fkie.fraunhofer.de Mon Jan 21 06:37:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A621F84F9 for ; Mon, 21 Jan 2013 06:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmQ-WUT8fZIk for ; Mon, 21 Jan 2013 06:37:51 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF3E21F851E for ; Mon, 21 Jan 2013 06:37:50 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxIVR-0005kE-DL; Mon, 21 Jan 2013 15:37:49 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxIVR-000476-Ag; Mon, 21 Jan 2013 15:37:49 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jan 2013 15:37:48 +0100 Message-ID: <50FD52BB.20504@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 15:37:47 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090904050601080105040307" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16539/Mon Jan 21 14:42:07 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c9c66f32f18f586296172d92028f39d6 Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:37:51 -0000 --------------ms090904050601080105040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/21/2013 03:34 PM, Abdussalam Baryun wrote: > Hi Henning > > The below draft explains how OLSRv2 is used in funkfeuer, but not sure > of interoperability with other routers; please advise, > > http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 I suggest reading the document. Its NOT about how OLSRv2 is used in Funkfeuer. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090904050601080105040307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjExNDM3NDdaMCMGCSqGSIb3DQEJBDEWBBRR2zJKUmESpUWN4MYClaYCtn/O9zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAEhrIDen9ZXrXsMMgpMSqJ6T8POyYGoYmKESdsIiTyDWO BHQEp6c3jalINY1zk72ZavVb8Ut+SxirPY69aGtDkrHRNvJ1aADTqEmjkzBAZ2WvUUEMTt/g cXj0VwnCuuUdwMCDErQuIBp8D5ik70ngJKRuLUfoH9iH9qa/dTlFRI2t3piTJA4uNEhqOF09 QRh+6jGgZlOcMneZhi7gdKghlSREUokMSBfI7kTyyzZfbVKjd3wFDnCjztrsdgDh8lD5VqUv w369HRst/ZNKOP4n3foRNRVNG60ZNzDkVh6ixmiDgYkbSFOiW7Xn+emaLpHTyLrvh3NVeixC 0+kVa8U8nQAAAAAAAA== --------------ms090904050601080105040307-- From charliep@computer.org Mon Jan 21 09:33:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE6021F857C for ; Mon, 21 Jan 2013 09:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YOyddCwfCQu for ; Mon, 21 Jan 2013 09:33:18 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id A3C8821F850F for ; Mon, 21 Jan 2013 09:33:18 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxLFE-0006nQ-V7; Mon, 21 Jan 2013 12:33:17 -0500 Message-ID: <50FD7BD3.1050803@computer.org> Date: Mon, 21 Jan 2013 09:33:07 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010002020907000404080900" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e490b032e80061a3cebf29a7c22133fc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:33:23 -0000 This is a multi-part message in MIME format. --------------010002020907000404080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Ulrich, First, let's agree that, all other things being equal, position independence is better than positional dependence. Then, it's a matter of trading off that positive feature versus other potential negatives. In the extreme, no one would add a kilobyte to the header just to preserve position independence. Next, please observe that Henning has proposed a change to RteMsg design that offers positional independence. I hope to write it up today for evaluation. Third, we have lots of experience with positional dependent designs that are extensible -- not related to [manet]. To me this is almost a no-brainer, but I also know that the RFC 5444 (and, perhaps more inclusively, the XML) experts have relevant experience. Using the same parser is, in my view, not a factor that should determine the outcome of this design decision. If adding bytes to the header causes more rapid depletion of radio transceiver batteries, then trying to inherit someone else's parser is optimizing the wrong thing. If we all took the time to analyze and argue this out in gory detail, I think we could come to some consensus position, but I also don't think that is where we should spend our time right now. Fourth, I think there are some noticeable problems with RFC 5444 that need fixing, but I have avoided making that into part of the discussion about reactive protocols. For now, the task is to make RFC 5444 serve the purpose which it is mandated to serve. That has proved difficult enough. The discussion seems to be devolving into something of a religious war, with any criticism being *dismissed* as irrelevant. I have neither the time nor the inclination to fight it. Regards, Charlie P. On 1/15/2013 12:36 PM, Ulrich Herberg wrote: > Hello Charlie, > > I agree with Chris and Henning on this matter. You mention extensions > for AODV where no problems have been observed. I think part of the > reasons is that they (presumably) did not have to interoperate with > other implementations that did not support that extension (no multiple > vendors / multiple implementations in the same network). Henning > mentioned to me once that his OLSR.org (OLSRv1) implementation has > some extensions by having a different message type (I am sure he has > more details). Sure, that works fine, as long as there are no other > routers in the network that do not use the extension, and that > therefore cannot know about the new message type. > The problem with fixed positions and lengths is that it's hard to > extend, and to remain backwards compatible / interoperable, which is a > very nice feature about OLSRv2. You can still interoperate routers > that only speak the "base" OLSRv2 and others that have extensions and > attach new addresses and TLVs in any order or position or address > block they want. You can use a common RFC5444 parser and generator for > all of them. The flexibility and extensibility of OLSRv2 was one of > the main reasons for developing it (compared to OLSR"v1"), and one of > the main reasons the MANET WG standardized RFC5444. > I have from my implementation experience, both for LOADng and OLSRv2 > for which I developed multiple extensions, always appreciated this > design choice. It made it very easy to develop in a very modular > style, and not care much about backward compatibility. > > I think it would be useful to have a BCP for RFC5444 on that matter. > > Best regards > Ulrich > > On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins > > wrote: > > > Hello Abdussalam, > > > On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: > > > I agree with chris, that it is hard to extend when we are > having in > our design function a general manet packet format and fix position > reactive message format, because I don't have a good knowledge of > future, nor the best ways of using manet message formats, but the > thing is that; > > > On the one hand, it's probably true that placing positional > constraints > on top of RFC 5444 constraints makes future designs harder (that is > almost a tautology). Similarly, placing RFC 5444 constraints has > itself > made future designs more difficult. > > On other hand, there's a lot of protocols out there that have > positional > constraints (at all layers!) and we know how to do that. In > particular, > AODV (the experimental protocol) did not seem to encounter any > difficulty with extensions, many of which never made it to the IETF, > and I don't remember any complaint about the positional nature of > AODV parameters in the message formats until this discussion. > > So, for all practical purposes, the argument that "positional == bad" > simply does not match my experience. As in many situations, each > design deserves its own consideration. If positional designs make the > packets smaller, that deserves to be considered, especially for > wireless. > > I remember some recent discussion that there are more processor > cycles than battery lifetime, which would motivate saving bytes over > the air. It is always a tradeoff. > > > > That is maybe because the protocols were not implemented widely. > however, It is good that we now think in that direction for future > protocols in IETF. > > > If this is a serious feature that is needed before we go forward with > next steps, I can try to compose some specification language for it. > I don't think it's too hard to do. > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------010002020907000404080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Ulrich,

First, let's agree that, all other things being equal, position independence
is better than positional dependence.  Then, it's a matter of trading off
that positive feature versus other potential negatives.  In the extreme,
no one would add a kilobyte to the header just to preserve position
independence.

Next, please observe that Henning has proposed a change to RteMsg
design that offers positional independence.  I hope to write it up today
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the same
parser is, in my view, not a factor that should determine the outcome
of this design decision.  If adding bytes to the header causes more rapid
depletion of radio transceiver batteries, then trying to inherit someone
else's parser is optimizing the wrong thing.  If we all took the time to
analyze and argue this out in gory detail, I think we could come to some
consensus position, but I also don't think that is where we should spend
our time right now.

Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols.  For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has
proved difficult enough.  The discussion seems to be devolving into
something of a religious war, with any criticism being *dismissed*
as irrelevant.  I have neither the time nor the inclination to fight it.

Regards,
Charlie P.


On 1/15/2013 12:36 PM, Ulrich Herberg wrote:
Hello Charlie,

I agree with Chris and Henning on this matter. You mention extensions for AODV where no problems have been observed. I think part of the reasons is that they (presumably) did not have to interoperate with other implementations that did not support that extension (no multiple vendors / multiple implementations in the same network). Henning mentioned to me once that his OLSR.org (OLSRv1) implementation has some extensions by having a different message type (I am sure he has more details). Sure, that works fine, as long as there are no other routers in the network that do not use the extension, and that therefore cannot know about the new message type.
The problem with fixed positions and lengths is that it's hard to extend, and to remain backwards compatible / interoperable, which is a very nice feature about OLSRv2. You can still interoperate routers that only speak the "base" OLSRv2 and others that have extensions and attach new addresses and TLVs in any order or position or address block they want. You can use a common RFC5444 parser and generator for all of them. The flexibility and extensibility of OLSRv2 was one of the main reasons for developing it (compared to OLSR"v1"), and one of the main reasons the MANET WG standardized RFC5444.
I have from my implementation experience, both for LOADng and OLSRv2 for which I developed multiple extensions, always appreciated this design choice. It made it very easy to develop in a very modular style, and not care much about backward compatibility.

I think it would be useful to have a BCP for RFC5444 on that matter.

Best regards
Ulrich

On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins <charliep@computer.org> wrote:

Hello Abdussalam,


On 1/15/2013 11:14 AM, Abdussalam Baryun wrote:

I agree with chris, that it is hard to extend when we are having in
our design function a general manet packet format and fix position
reactive message format, because I don't have a good knowledge of
future, nor the best ways of using manet message formats, but the
thing is that;

On the one hand, it's probably true that placing positional constraints
on top of RFC 5444 constraints makes future designs harder (that is
almost a tautology).  Similarly, placing RFC 5444 constraints has itself
made future designs more difficult.

On other hand, there's a lot of protocols out there that have positional
constraints (at all layers!) and we know how to do that.  In particular,
AODV (the experimental protocol) did not seem to encounter any
difficulty with extensions, many of which never made it to the IETF,
and I don't remember any complaint about the positional nature of
AODV parameters in the message formats until this discussion.

So, for all practical purposes, the argument that "positional == bad"
simply does not match my experience.  As in many situations, each
design deserves its own consideration.  If positional designs make the
packets smaller, that deserves to be considered, especially for wireless.

I remember some recent discussion that there are more processor
cycles than battery lifetime, which would motivate saving bytes over
the air.  It is always a tradeoff.



That is maybe because the protocols were not implemented widely.
however, It is good that we now think in that direction for future
protocols in IETF.

If this is a serious feature that is needed before we go forward with
next steps, I can try to compose some specification language for it.
I don't think it's too hard to do.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------010002020907000404080900-- From ulrich@herberg.name Mon Jan 21 09:44:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A836821F85D2 for ; Mon, 21 Jan 2013 09:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEOpHa9c2Cwb for ; Mon, 21 Jan 2013 09:44:43 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABDC21F856D for ; Mon, 21 Jan 2013 09:44:42 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id n11so3968483vch.33 for ; Mon, 21 Jan 2013 09:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4hNSEAPioH5gJQVafblwLzCCoTtLLD+komi12zP4XZw=; b=nCpS0Ic/go8ufoaT3KrZKk5bucjge0uSTyQgCrgvGfjR2yBhusFAqZrdROpna7U+C8 wz1VShWA1aEHqu8FxYFtYhtoQJ5beGmPw54zs4QsnCEi29b1C06gW0IJr+K2mlSc0aix ySc2QQVeeLBCfEmgBJ/Yevzk470/6zhRrEjxw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=4hNSEAPioH5gJQVafblwLzCCoTtLLD+komi12zP4XZw=; b=nYSqsN6gjGJM9guEko8wEUV5QCpdDtsSZuI4r1c9eckXKpFx9wEbnKvAD7fkBH/LUA IAdMOeiNiT4Wasd2Bfrq6s0mgUuts76JDlS/MzDWbtc1XJOaOWvX40GWvsPfTcmv+NHe 1QNtfFAtMGC4FBfE7eAcD8pgxUPXPP/YPTmqs3hsLZ7haj6wp57SJHVJT4g7fmdF2fND MoPyCDww5PLsdpYVKWDzmaYzCcw/BiGnY8KkMhvAV1b9moP8yvagGoTwqV1ouiDi3p5C r7ftG/YV1jAiC1tibkC2cI/9ZM7R6u8oDD34zU5GdkzVwcV4zj856eiTVDqBjxFqeq2v otKw== MIME-Version: 1.0 X-Received: by 10.220.219.145 with SMTP id hu17mr20050128vcb.52.1358790281873; Mon, 21 Jan 2013 09:44:41 -0800 (PST) Received: by 10.220.33.143 with HTTP; Mon, 21 Jan 2013 09:44:41 -0800 (PST) In-Reply-To: <50FD7BD3.1050803@computer.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> Date: Mon, 21 Jan 2013 09:44:41 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=14dae9cfce94134a7904d3d00406 X-Gm-Message-State: ALoCoQmhpA4Vru/qAET0ZcpPueNr8iNGXs9wzdo697FKVpaBGGV6v14qL8YSa7cvf+eOUtD0p60X Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:44:44 -0000 --14dae9cfce94134a7904d3d00406 Content-Type: text/plain; charset=ISO-8859-1 Hello Charlie On Mon, Jan 21, 2013 at 9:33 AM, Charles E. Perkins wrote: > [...] > > Fourth, I think there are some noticeable problems with RFC 5444 > that need fixing, but I have avoided making that into part of the > discussion about reactive protocols. For now, the task is to make > RFC 5444 serve the purpose which it is mandated to serve. That has > proved difficult enough. The discussion seems to be devolving into > something of a religious war, with any criticism being *dismissed* > as irrelevant. I have neither the time nor the inclination to fight it. > I haven't seen any "religious war". I have seen arguing 5 or 6 people (including multiple RFC5444 authors) against positional dependence and 1 person in favor. I would call that "rough consensus", not "dismissal". (Moreover, by having standardized RFC5444 and RFC5498, there is more evidence of consensus in the WG on the usage of RFC5444 long before this discussion). Best regards Ulrich --14dae9cfce94134a7904d3d00406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Charlie

On Mon, Jan 21, 2013 at 9:3= 3 AM, Charles E. Perkins <charliep@computer.org> wrote:<= br>
=20 =20 =20
[...]

Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols.=A0 For now, the task is to make<= br> RFC 5444 serve the purpose which it is mandated to serve.=A0 That has
proved difficult enough.=A0 The discussion seems to be devolving into
something of a religious war, with any criticism being *dismissed* as irrelevant.=A0 I have neither the time nor the inclination to fight it.


I haven't seen= any "religious war". I have seen arguing 5 or 6 people (includin= g multiple RFC5444 authors) against positional dependence and 1 person in f= avor. I would call that "rough consensus", not "dismissal&qu= ot;. (Moreover, by having standardized RFC5444 and RFC5498, there is more e= vidence of consensus in the WG on the usage of RFC5444 long before this dis= cussion).

Best regards
Ulrich
--14dae9cfce94134a7904d3d00406-- From abdussalambaryun@gmail.com Mon Jan 21 11:41:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32A321F852C for ; Mon, 21 Jan 2013 11:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j-uMjSsUk-Y for ; Mon, 21 Jan 2013 11:41:05 -0800 (PST) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4973621F8526 for ; Mon, 21 Jan 2013 11:41:05 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id un1so2843535pbc.12 for ; Mon, 21 Jan 2013 11:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nt7Ebsoo+/26X8HIHF0w01Rno7TepZD1BT+oz4R6zpw=; b=N/PQpMctx9h+gfZ85EizmgYbs6lXKv/mssB0Bheg2cnL1XK1POu7HVA8OE9j0p4epa BwtDwTaK9VW4SvEc6z1usIJLDGrxF7/6kd7X+QyWmzLX0TrgYEh5/SMQ1wJLVjhzULU6 oQoXj7Zm3Ooy/SsUQcXNB/EEro/820g3+Y+RdGnuqYhl1K09FaGnF9UFNzs+3fgSPk0d Puq1HFN4D1fduIlAnI+7K6szUTI1eqssiL8OQ41R8FFjlIkE4zJpID0qLhNhadjge8X5 snDwaZ9FGwUWczrLMUz8ddy17OfAQ59tRNp+Tjqu/PB1ZKUasnL8xDYNB2BQu57/Qy1s ueIw== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr32525630pbb.43.1358797265095; Mon, 21 Jan 2013 11:41:05 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 11:41:04 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> Date: Mon, 21 Jan 2013 20:41:04 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:41:05 -0000 On 1/21/13, Ulrich Herberg wrote: > > I haven't seen any "religious war". I have seen arguing 5 or 6 people > (including multiple RFC5444 authors) against positional dependence and 1 > person in favor. It was 5 not 6, and for positional dependence was 3 (includes me, but I prefer mix), so I think no concensus, IMHO, we still should go through this discussion, but to relate the decision to reason and engineering knowledge. >I would call that "rough consensus", not "dismissal". > (Moreover, by having standardized RFC5444 and RFC5498, there is more > evidence of consensus in the WG on the usage of RFC5444 long before this > discussion). Any RFC may be updated in future or at any time because of new knowledge, or even RFCs may be obsoleted by others. As someone just mention lets focus on our documents to meet the milestones, AB From abdussalambaryun@gmail.com Mon Jan 21 11:50:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492F221F84B6 for ; Mon, 21 Jan 2013 11:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUp6lYDcaoEy for ; Mon, 21 Jan 2013 11:50:53 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5861621F8450 for ; Mon, 21 Jan 2013 11:50:53 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so2863171dan.9 for ; Mon, 21 Jan 2013 11:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ym19OfCCMNrRYAfdhNlnhwu6Zp/Lw9zWL3BUfVkM9E8=; b=ZRM7/i7c9qGNL1dalXb+FZcysDzR3gcTlyTdVH4du2DqW4sWti+lHwrznUsEm+E+Ma yhZV0iAcp0jGJLVc19Ox9kCr+0XKtFENlwcPLtIuKw/9hEpEjGx8av8CvZrAdTHQobHR lEn8s1caItgTkvkTdWIJ26vS3fKtO1VWpL0YoN5t4FQyl0sMdCVvpsplBu33Ypp0Tt// ErKFsam1+jkxP9aH3RVzryyH1qyEdvDk+85oMTPZPUxF/fM2Hxb916KxytIkQ/SiowZg SUbpEGZMMANoiUF1rejj7v8Vk4bf5goUb97QXsWsY6DzOVfmEqVWCS7iUKRWTm2/PW/p mEvw== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr32590589pbb.43.1358797850401; Mon, 21 Jan 2013 11:50:50 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 11:50:50 -0800 (PST) In-Reply-To: <50FD7BD3.1050803@computer.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> Date: Mon, 21 Jan 2013 20:50:50 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:50:54 -0000 On 1/21/13, Charles E. Perkins wrote: > Fourth, I think there are some noticeable problems with RFC 5444 > that need fixing, but I have avoided making that into part of the > discussion about reactive protocols. For now, the task is to make > RFC 5444 serve the purpose which it is mandated to serve. That has > proved difficult enough. The discussion seems to be devolving into > something of a religious war, with any criticism being *dismissed* > as irrelevant. I have neither the time nor the inclination to fight it. I mentioned that there may be enhancements to RFC5444 (I may be wrong, but any RFC including 5444 may need enhacement) after reading some inputs and thinking of designing a new manet protocol, however, I agree/support that we postpone this issue until we submit the first proposed standrard reactive protocol. AB From charliep@computer.org Mon Jan 21 12:00:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97021F86AA for ; Mon, 21 Jan 2013 12:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TEVd0O9O3lo for ; Mon, 21 Jan 2013 12:00:25 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 176BC21F8505 for ; Mon, 21 Jan 2013 12:00:25 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxNXX-0005T8-N2; Mon, 21 Jan 2013 15:00:19 -0500 Message-ID: <50FD9E4A.7010807@computer.org> Date: Mon, 21 Jan 2013 12:00:10 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8607c37a20787284ca60072269b0a736e4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 20:00:26 -0000 Hello folks, As Henning has proposed, it is possible to revise the AODVv2 Address TLV definitions so that in the base protocol, the AddrBlk addresses do not need to have any additional position-based semantics. I have made some example packet formats and definitions, herewith... ========================================================== "Route Discovery Originator Sequence Number": The sequence number for the originating node that triggered the RREQ message initiating the Route Discovery operation. Another TLV for "Route Discovery Target Sequence Number" The sequence number for the target node for which a route was requested by way of RREQ from the originating router. The following packet formats look best with fixed-width fonts. If I didn't get all the RFC 5444 bits correct, please don't shoot me, but I think they're correct. Original: SeqNum TLV shown with an example AddrBlk: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=6 | type=SeqNum |0|1|0|1|0|0|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One Sequence Number: Original Node SeqNum TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=6 | type=OSeqNum |0|1|0|1|0|0|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One Sequence Number: Target Node SeqNum TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=6 | type=TSeqNum |0|1|0|1|0|0|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=1 | tlv-length=2 | Targ.Node Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two Sequence Numbers: SeqNum TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=7 | type=SeqNum |0|0|0|1|0|1|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tlv-length=4 | Orig.Node Sequence # | TargNode Seq# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargNode Seq# | +-+-+-+-+-+-+-+-+ Two Sequence Numbers: Originating and Target Node SeqNum TLVs: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=12 | type=OSeqNum |0|1|0|1|0|0|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=TSeqNum |0|1|0|1|0|0|Rsv| Index-start=1 | tlv-length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Targ.Node Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I propose to replace the existing AODVv2 TLVs with the TLVs defined above, and to move the positional-dependent SeqNum TLV to iRREP specification. -- Regards, Charlie P. From abdussalambaryun@gmail.com Mon Jan 21 12:01:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2F321F8632 for ; Mon, 21 Jan 2013 12:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gri2qZKmj61 for ; Mon, 21 Jan 2013 12:01:35 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9FE21F865D for ; Mon, 21 Jan 2013 12:01:35 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ro2so3491860pbb.25 for ; Mon, 21 Jan 2013 12:01:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UfpcCv+wppSbJOCfGm69Ly9PLQ2X4mMxlwrSwSpdYEk=; b=o5ReFZv1GGlHzIMfiJj6jKTSxySInVhWmyGacgzcIIRBsbYGz0FMC9Gn77Eo1WDuQF PdXpYH/iKy/86vy6B7XTrO0kQn7/0gm8vBHn0WpjpoDTkap61IqUCObbFg9OfDEjqGgN lxtRkD0SS0LMSKJpckdTTJoJi58AF8DKfiaIb1K3MSUrS80+/mF8R91K5vy+7i5GHfLf iS1X9F7+bKgl5akW0SlJl+50DPSee4vkHkU3noBAIBr4baHiVEOyT+57Dk95s9sgSujp rtL9EPWwN+/ie5xLWC1b2vq1dqRaAS/lOiZ8Dp72kn4Vy6wRFls0ExHqBaWyxBV5G1PF Ux5w== MIME-Version: 1.0 X-Received: by 10.68.136.132 with SMTP id qa4mr32341408pbb.166.1358798495255; Mon, 21 Jan 2013 12:01:35 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 21 Jan 2013 12:01:35 -0800 (PST) In-Reply-To: <50FD52BB.20504@fkie.fraunhofer.de> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7723212792@xmb-rcd-x02.cisco.com> <50FCE97D.3080501@fkie.fraunhofer.de> <50FD2D5C.6010902@fkie.fraunhofer.de> <50FD52BB.20504@fkie.fraunhofer.de> Date: Mon, 21 Jan 2013 21:01:35 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 20:01:36 -0000 Thanks alot, I will follow your advise, AB On 1/21/13, Henning Rogge wrote: > On 01/21/2013 03:34 PM, Abdussalam Baryun wrote: >> Hi Henning >> >> The below draft explains how OLSRv2 is used in funkfeuer, but not sure >> of interoperability with other routers; please advise, >> >> http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 > > I suggest reading the document. > > Its NOT about how OLSRv2 is used in Funkfeuer. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From ietf@thomasclausen.org Mon Jan 21 12:37:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3862721F8556 for ; Mon, 21 Jan 2013 12:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ7UzqeqlRmx for ; Mon, 21 Jan 2013 12:37:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0521F8551 for ; Mon, 21 Jan 2013 12:37:32 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 54C7D557F64 for ; Mon, 21 Jan 2013 12:37:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1DE961C05B7; Mon, 21 Jan 2013 12:37:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0A45E1C045B; Mon, 21 Jan 2013 12:37:31 -0800 (PST) References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50FD7BD3.1050803@computer.org> Content-Type: multipart/alternative; boundary=Apple-Mail-F7FB63ED-C770-4B56-ACB9-97E5DFD2A689 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Mon, 21 Jan 2013 21:37:30 +0100 To: "Charles E. Perkins" Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 20:37:34 -0000 --Apple-Mail-F7FB63ED-C770-4B56-ACB9-97E5DFD2A689 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 21 janv. 2013, at 18:33, "Charles E. Perkins" wro= te: > Hello Ulrich, >=20 > First, let's agree that, all other things being equal, position independen= ce > is better than positional dependence. Then, it's a matter of trading off > that positive feature versus other potential negatives. In the extreme, > no one would add a kilobyte to the header just to preserve position > independence. Reductio ad absurdum. > Next, please observe that Henning has proposed a change to RteMsg > design that offers positional independence. I hope to write it up today > for evaluation. >=20 > Third, we have lots of experience with positional dependent designs > that are extensible -- not related to [manet]. To me this is almost a > no-brainer, but I also know that the RFC 5444 (and, perhaps more > inclusively, the XML) experts have relevant experience. Using the same > parser is, in my view, not a factor that should determine the outcome > of this design decision.=20 That is, then, because you have not been in the business of implementing pro= tocols and multi-protocol MANET routers. It is a HUGE benefit to be able to s= hare parsing code, especially given that 5444 is (if used properly) both fle= xible, efficient to parse and efficient in encoding messages. It also gives y= ou some nice benefits of running multiple protocols jointly (as is the case w= ith NHDP/OLSRv2/SMF) on the same device.=20 Same benefits apply if you run LOADng/OLSRv2/NHDP together. > If adding bytes to the header causes more rapid > depletion of radio transceiver batteries, then trying to inherit someone > else's parser is optimizing the wrong thing. If we all took the time to > analyze and argue this out in gory detail, I think we could come to some > consensus position, but I also don't think that is where we should spend > our time right now. >=20 > Fourth, I think there are some noticeable problems with RFC 5444 > that need fixing, but I have avoided making that into part of the > discussion about reactive protocols.=20 Unless you are willing to make the arguments, please don't spread such misin= formation. > For now, the task is to make > RFC 5444 serve the purpose which it is mandated to serve. That has > proved difficult enough.=20 This is wrong. A multitude of MANET protocols have been designed to use RFC5444, including r= eactive protocols, without any problems. It's extremely easy, even, once one understands RFC5444. > The discussion seems to be devolving into > something of a religious war, with any criticism being *dismissed* > as irrelevant. I have neither the time nor the inclination to fight it. I am not going to respond to that directly.=20 I would appreciate technical arguments, rather than strawman's and assertion= s.=20 Thomas > Regards, > Charlie P. >=20 >=20 > On 1/15/2013 12:36 PM, Ulrich Herberg wrote: >> Hello Charlie, >>=20 >> I agree with Chris and Henning on this matter. You mention extensions for= AODV where no problems have been observed. I think part of the reasons is t= hat they (presumably) did not have to interoperate with other implementation= s that did not support that extension (no multiple vendors / multiple implem= entations in the same network). Henning mentioned to me once that his OLSR.o= rg (OLSRv1) implementation has some extensions by having a different message= type (I am sure he has more details). Sure, that works fine, as long as the= re are no other routers in the network that do not use the extension, and th= at therefore cannot know about the new message type.=20 >> The problem with fixed positions and lengths is that it's hard to extend,= and to remain backwards compatible / interoperable, which is a very nice fe= ature about OLSRv2. You can still interoperate routers that only speak the "= base" OLSRv2 and others that have extensions and attach new addresses and TL= Vs in any order or position or address block they want. You can use a common= RFC5444 parser and generator for all of them. The flexibility and extensibi= lity of OLSRv2 was one of the main reasons for developing it (compared to OL= SR"v1"), and one of the main reasons the MANET WG standardized RFC5444.=20 >> I have from my implementation experience, both for LOADng and OLSRv2 for w= hich I developed multiple extensions, always appreciated this design choice.= It made it very easy to develop in a very modular style, and not care much a= bout backward compatibility. >>=20 >> I think it would be useful to have a BCP for RFC5444 on that matter. >>=20 >> Best regards >> Ulrich >>=20 >> On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins wrote: >>>=20 >>> Hello Abdussalam, >>>=20 >>>=20 >>> On 1/15/2013 11:14 AM, Abdussalam Baryun wrote: >>>>=20 >>>> I agree with chris, that it is hard to extend when we are having in >>>> our design function a general manet packet format and fix position >>>> reactive message format, because I don't have a good knowledge of >>>> future, nor the best ways of using manet message formats, but the >>>> thing is that; >>>=20 >>> On the one hand, it's probably true that placing positional constraints >>> on top of RFC 5444 constraints makes future designs harder (that is >>> almost a tautology). Similarly, placing RFC 5444 constraints has itself= >>> made future designs more difficult. >>>=20 >>> On other hand, there's a lot of protocols out there that have positional= >>> constraints (at all layers!) and we know how to do that. In particular,= >>> AODV (the experimental protocol) did not seem to encounter any >>> difficulty with extensions, many of which never made it to the IETF, >>> and I don't remember any complaint about the positional nature of >>> AODV parameters in the message formats until this discussion. >>>=20 >>> So, for all practical purposes, the argument that "positional =3D=3D bad= " >>> simply does not match my experience. As in many situations, each >>> design deserves its own consideration. If positional designs make the >>> packets smaller, that deserves to be considered, especially for wireless= . >>>=20 >>> I remember some recent discussion that there are more processor >>> cycles than battery lifetime, which would motivate saving bytes over >>> the air. It is always a tradeoff. >>>=20 >>>=20 >>>>=20 >>>> That is maybe because the protocols were not implemented widely. >>>> however, It is good that we now think in that direction for future >>>> protocols in IETF. >>>=20 >>> If this is a serious feature that is needed before we go forward with >>> next steps, I can try to compose some specification language for it. >>> I don't think it's too hard to do. >>>=20 >>> --=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > --=20 > Regards, > Charlie P. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-F7FB63ED-C770-4B56-ACB9-97E5DFD2A689 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 21 janv. 2013, at 18:33, "Charles E. Perkins" <charliep@computer.org> wrote:

Hello Ulrich,

First, let's agree that, all other things being equal, position independence
is better than positional dependence.  Then, it's a matter of trading off
that positive feature versus other potential negatives.  In the extreme,
no one would add a kilobyte to the header just to preserve position
independence.

Reductio ad absurdum.

Next, please observe that Henning has proposed a change to RteMsg
design that offers positional independence.  I hope to write it up today
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the same
parser is, in my view, not a factor that should determine the outcome
of this design decision. 

That is, then, because you have not been in the business of implementing protocols and multi-protocol MANET routers. It is a HUGE benefit to be able to share parsing code, especially given that 5444 is (if used properly) both flexible, efficient to parse and efficient in encoding messages. It also gives you some nice benefits of running multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on the same device. 

Same benefits apply if you run LOADng/OLSRv2/NHDP together.

If adding bytes to the header causes more rapid
depletion of radio transceiver batteries, then trying to inherit someone
else's parser is optimizing the wrong thing.  If we all took the time to
analyze and argue this out in gory detail, I think we could come to some
consensus position, but I also don't think that is where we should spend
our time right now.

Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols. 

Unless you are willing to make the arguments, please don't spread such misinformation.

For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has
proved difficult enough. 

This is wrong.

A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

The discussion seems to be devolving into
something of a religious war, with any criticism being *dismissed*
as irrelevant.  I have neither the time nor the inclination to fight it.

I am not going to respond to that directly. 

I would appreciate technical arguments, rather than strawman's and assertions. 

Thomas

Regards,
Charlie P.


On 1/15/2013 12:36 PM, Ulrich Herberg wrote:
Hello Charlie,

I agree with Chris and Henning on this matter. You mention extensions for AODV where no problems have been observed. I think part of the reasons is that they (presumably) did not have to interoperate with other implementations that did not support that extension (no multiple vendors / multiple implementations in the same network). Henning mentioned to me once that his OLSR.org (OLSRv1) implementation has some extensions by having a different message type (I am sure he has more details). Sure, that works fine, as long as there are no other routers in the network that do not use the extension, and that therefore cannot know about the new message type.
The problem with fixed positions and lengths is that it's hard to extend, and to remain backwards compatible / interoperable, which is a very nice feature about OLSRv2. You can still interoperate routers that only speak the "base" OLSRv2 and others that have extensions and attach new addresses and TLVs in any order or position or address block they want. You can use a common RFC5444 parser and generator for all of them. The flexibility and extensibility of OLSRv2 was one of the main reasons for developing it (compared to OLSR"v1"), and one of the main reasons the MANET WG standardized RFC5444.
I have from my implementation experience, both for LOADng and OLSRv2 for which I developed multiple extensions, always appreciated this design choice. It made it very easy to develop in a very modular style, and not care much about backward compatibility.

I think it would be useful to have a BCP for RFC5444 on that matter.

Best regards
Ulrich

On Tue, Jan 15, 2013 at 11:59 AM, Charles E. Perkins <charliep@computer.org> wrote:

Hello Abdussalam,


On 1/15/2013 11:14 AM, Abdussalam Baryun wrote:

I agree with chris, that it is hard to extend when we are having in
our design function a general manet packet format and fix position
reactive message format, because I don't have a good knowledge of
future, nor the best ways of using manet message formats, but the
thing is that;

On the one hand, it's probably true that placing positional constraints
on top of RFC 5444 constraints makes future designs harder (that is
almost a tautology).  Similarly, placing RFC 5444 constraints has itself
made future designs more difficult.

On other hand, there's a lot of protocols out there that have positional
constraints (at all layers!) and we know how to do that.  In particular,
AODV (the experimental protocol) did not seem to encounter any
difficulty with extensions, many of which never made it to the IETF,
and I don't remember any complaint about the positional nature of
AODV parameters in the message formats until this discussion.

So, for all practical purposes, the argument that "positional == bad"
simply does not match my experience.  As in many situations, each
design deserves its own consideration.  If positional designs make the
packets smaller, that deserves to be considered, especially for wireless.

I remember some recent discussion that there are more processor
cycles than battery lifetime, which would motivate saving bytes over
the air.  It is always a tradeoff.



That is maybe because the protocols were not implemented widely.
however, It is good that we now think in that direction for future
protocols in IETF.

If this is a serious feature that is needed before we go forward with
next steps, I can try to compose some specification language for it.
I don't think it's too hard to do.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-F7FB63ED-C770-4B56-ACB9-97E5DFD2A689-- From charliep@computer.org Mon Jan 21 13:03:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B928B21F8654 for ; Mon, 21 Jan 2013 13:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-zD6wRhzGyk for ; Mon, 21 Jan 2013 13:03:40 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id C818221F873B for ; Mon, 21 Jan 2013 13:03:39 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxOWp-0007pD-0s; Mon, 21 Jan 2013 16:03:39 -0500 Message-ID: <50FDAD22.7080706@computer.org> Date: Mon, 21 Jan 2013 13:03:30 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Thomas Heide Clausen References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000606090607090307020800" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86a68cd78fd663cea9f5eabbf1b0843d54350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 21:03:40 -0000 This is a multi-part message in MIME format. --------------000606090607090307020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote: > > > On 21 janv. 2013, at 18:33, "Charles E. Perkins" > > wrote: > >> Hello Ulrich, >> >> First, let's agree that, all other things being equal, position >> independence >> is better than positional dependence. Then, it's a matter of trading off >> that positive feature versus other potential negatives. In the extreme, >> no one would add a kilobyte to the header just to preserve position >> independence. > > Reductio ad absurdum. Usually, the phrase "Reductio ad absurdum." is followed by QED. > >> Next, please observe that Henning has proposed a change to RteMsg >> design that offers positional independence. I hope to write it up today >> for evaluation. >> >> Third, we have lots of experience with positional dependent designs >> that are extensible -- not related to [manet]. To me this is almost a >> no-brainer, but I also know that the RFC 5444 (and, perhaps more >> inclusively, the XML) experts have relevant experience. Using the same >> parser is, in my view, not a factor that should determine the outcome >> of this design decision. > > That is, then, because you have not been in the business of > implementing protocols and multi-protocol MANET routers. It is a HUGE > benefit to be able to share parsing code, especially given that 5444 > is (if used properly) both flexible, efficient to parse and efficient > in encoding messages. It also gives you some nice benefits of running > multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on > the same device. So you'd rather optimize for parser development time over battery lifetime? At the beginning of my earlier email, I referred to "tradeoffs". I'll stand by that. I dispute the notion that one has trouble using multiple other protocols if one also uses a protocol with positional AddrBlks, and I'd be interested to see a specific counter-example. > >> >> >> Fourth, I think there are some noticeable problems with RFC 5444 >> that need fixing, but I have avoided making that into part of the >> discussion about reactive protocols. > > Unless you are willing to make the arguments, please don't spread such > misinformation. O.K. I'll bookmark your challenge and get back to it next month. > >> For now, the task is to make >> RFC 5444 serve the purpose which it is mandated to serve. That has >> proved difficult enough. > > This is wrong. Well, Ian spent a lot of time on it but couldn't do it so "easily". I don't consider myself a beginner, but I find it at minimum tedious and at worst error-prone. But -- I'm getting better at it. > > A multitude of MANET protocols have been designed to use RFC5444, > including reactive protocols, without any problems. > > It's extremely easy, even, once one understands RFC5444. See the above. If I am challenged to get testimonials to the contrary from other people, then I'll have to wait. I'm not at all interested in arguing about it, especially right now! I will at least say that other software developers seem more willing to accept feedback. -- Regards, Charlie P. --------------000606090607090307020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote:


On 21 janv. 2013, at 18:33, "Charles E. Perkins" <charliep@computer.org> wrote:

Hello Ulrich,

First, let's agree that, all other things being equal, position independence
is better than positional dependence.  Then, it's a matter of trading off
that positive feature versus other potential negatives.  In the extreme,
no one would add a kilobyte to the header just to preserve position
independence.

Reductio ad absurdum.

Usually, the phrase "Reductio ad absurdum." is followed by QED.


Next, please observe that Henning has proposed a change to RteMsg
design that offers positional independence.  I hope to write it up today
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the same
parser is, in my view, not a factor that should determine the outcome
of this design decision. 

That is, then, because you have not been in the business of implementing protocols and multi-protocol MANET routers. It is a HUGE benefit to be able to share parsing code, especially given that 5444 is (if used properly) both flexible, efficient to parse and efficient in encoding messages. It also gives you some nice benefits of running multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on the same device.

So you'd rather optimize for parser development time over
battery lifetime?   At the beginning of my earlier email, I
referred to "tradeoffs".  I'll stand by that.  I dispute the notion
that one has trouble using multiple other protocols if one also
uses a protocol with positional AddrBlks, and I'd be interested
to see a specific counter-example.





Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols. 

Unless you are willing to make the arguments, please don't spread such misinformation.

O.K.  I'll bookmark your challenge and get back to it next month.


For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has
proved difficult enough. 

This is wrong.

Well, Ian spent a lot of time on it but couldn't do it so "easily".
I don't consider myself a beginner, but I find it at minimum tedious
and at worst error-prone.  But -- I'm getting better at it.



A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

See the above.  If I am challenged to get testimonials to the
contrary from other people, then I'll have to wait.   I'm not at
all interested in arguing about it, especially right now!   I will
at least say that other software developers seem more willing
to accept feedback.

-- 
Regards,
Charlie P.
--------------000606090607090307020800-- From ulrich@herberg.name Mon Jan 21 13:16:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ED221F8551 for ; Mon, 21 Jan 2013 13:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF6ksYxzJfvz for ; Mon, 21 Jan 2013 13:16:11 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2226F21F8726 for ; Mon, 21 Jan 2013 13:16:11 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id fl15so1264659vcb.38 for ; Mon, 21 Jan 2013 13:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jmV8RZ3dSgUIRQbi9nnsXSn0o1t++1e7x0GVa4SlwMA=; b=x30HI5tOXYfwPntHmEbUf57Ukr6x6h749WaHa2OyNuIMNKpgM2okobSeQqH57eR999 vCRDan/KgHR81p5k++uK4TeRHk2oEHYa+/DBEd6vlCNpuZpvsqMBjXr261v7bjIsVJI0 0i9ONvCP9vy1diXUeu2r+7Dmcwv802iCDFYKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=jmV8RZ3dSgUIRQbi9nnsXSn0o1t++1e7x0GVa4SlwMA=; b=CywhZlg283ETDqlnGoN6VXkBiFgWwcgM1e/4ft2OI5A9erEDIGeXMKBClkHuvf8UbN HWBTo6h1V1mNjwAGhuj2aY0l5ZkMVK1rGp7IjjIqIVJMaxFOXX0xxpJVQLB3lgxAyATO 8Qf6jyP2L2Hbyea5M3vN2VDeK7P3mIW5IdrFIXHEC51KQ0e9kVLbNw73RrW8bxT8LkUt CMvdn4EBxWPE1v2UMI6ycmdYbjjfSi4CDq8Ms8g6x1s1jkERjaBZWKknVlvEPj4tSE90 NPQjBAQ+5Ca0r38DMn6Gu8KDtQ7YILnJYsopBxoqDhNaU1H71VLHJhAxCBZ71OE7r1nw LS0A== MIME-Version: 1.0 X-Received: by 10.52.67.79 with SMTP id l15mr12779669vdt.128.1358802969053; Mon, 21 Jan 2013 13:16:09 -0800 (PST) Received: by 10.220.33.143 with HTTP; Mon, 21 Jan 2013 13:16:08 -0800 (PST) In-Reply-To: <50FDAD22.7080706@computer.org> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> Date: Mon, 21 Jan 2013 13:16:08 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf307f34fe4a4b3204d3d2f8e8 X-Gm-Message-State: ALoCoQme3GO31dd3q1Ts86bHBHnxrpNBjEIOCpZaEJIA/1NLjLjYz4sPui7z0PWkjFmTtWoEXG2U Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 21:16:12 -0000 --20cf307f34fe4a4b3204d3d2f8e8 Content-Type: text/plain; charset=ISO-8859-1 Charlie, On Mon, Jan 21, 2013 at 1:03 PM, Charles E. Perkins wrote: > > For now, the task is to make > RFC 5444 serve the purpose which it is mandated to serve. That has > proved difficult enough. > > > This is wrong. > > > Well, Ian spent a lot of time on it but couldn't do it so "easily". > I don't consider myself a beginner, but I find it at minimum tedious > and at worst error-prone. But -- I'm getting better at it. When I changed our LOADng implementation from a fixed packet format to RFC5444, it did not take me more than two days (that includes implementing RFC5444). I did not think it was hard. And it was not error-prone, as shown by an interop test that I did soon after that update, which was very successful after only little time fixing minimal bugs. Therefore, I cannot confirm that it is "tedious" or "error-prone". Best regards Ulrich --20cf307f34fe4a4b3204d3d2f8e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Charlie,

On Mon, Jan 21, 2013 at 1:03 PM,= Charles E. Perkins <charliep@computer.org> wrote:

For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.=A0 That has
proved difficult enough.=A0

This is wrong.

Well, Ian spent a lot of time on it but couldn't do it so "eas= ily".
I don't consider myself a beginner, but I find it at minimum tediou= s
and at worst error-prone.=A0 But -- I'm getting better at it.


When I changed our LOADng implementation from a fixed p= acket format to RFC5444, it did not take me more than two days (that includ= es implementing RFC5444). I did not think it was hard. And it was not error= -prone, as shown by an interop test that I did soon after that update, whic= h was very successful after only little time fixing minimal bugs. Therefore= , I cannot confirm that it is "tedious" or "error-prone"= ;.

Best regards
Ulrich
=A0


--20cf307f34fe4a4b3204d3d2f8e8-- From ietf@thomasclausen.org Mon Jan 21 13:18:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F367921F8552 for ; Mon, 21 Jan 2013 13:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+zkBhKcZEMG for ; Mon, 21 Jan 2013 13:18:02 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D996921F8551 for ; Mon, 21 Jan 2013 13:18:01 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 5D4D2A62FF for ; Mon, 21 Jan 2013 13:18:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 351FA1CA7F5; Mon, 21 Jan 2013 13:18:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 27B191C07FC; Mon, 21 Jan 2013 13:18:00 -0800 (PST) References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50FDAD22.7080706@computer.org> Content-Type: multipart/alternative; boundary=Apple-Mail-2DCA682B-5D89-4686-8981-23238D3C8D5F Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Mon, 21 Jan 2013 22:17:58 +0100 To: "Charles E. Perkins" Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 21:18:03 -0000 --Apple-Mail-2DCA682B-5D89-4686-8981-23238D3C8D5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 21 janv. 2013, at 22:03, "Charles E. Perkins" wro= te: > On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote: >>=20 >>=20 >> On 21 janv. 2013, at 18:33, "Charles E. Perkins" w= rote: >>=20 >>> Hello Ulrich, >>>=20 >>> First, let's agree that, all other things being equal, position independ= ence >>> is better than positional dependence. Then, it's a matter of trading of= f >>> that positive feature versus other potential negatives. In the extreme,= >>> no one would add a kilobyte to the header just to preserve position >>> independence. >>=20 >> Reductio ad absurdum. >=20 > Usually, the phrase "Reductio ad absurdum." is followed by QED. >=20 >>=20 >>> Next, please observe that Henning has proposed a change to RteMsg >>> design that offers positional independence. I hope to write it up today= >>> for evaluation. >>>=20 >>> Third, we have lots of experience with positional dependent designs >>> that are extensible -- not related to [manet]. To me this is almost a >>> no-brainer, but I also know that the RFC 5444 (and, perhaps more >>> inclusively, the XML) experts have relevant experience. Using the same >>> parser is, in my view, not a factor that should determine the outcome >>> of this design decision.=20 >>=20 >> That is, then, because you have not been in the business of implementing p= rotocols and multi-protocol MANET routers. It is a HUGE benefit to be able t= o share parsing code, especially given that 5444 is (if used properly) both f= lexible, efficient to parse and efficient in encoding messages. It also give= s you some nice benefits of running multiple protocols jointly (as is the ca= se with NHDP/OLSRv2/SMF) on the same device. >=20 > So you'd rather optimize for parser development time over > battery lifetime?=20 You assert that they're different? I've not observed the negative effects you describe above in real (battery c= onstrained) deployments. > At the beginning of my earlier email, I > referred to "tradeoffs". I'll stand by that. I dispute the notion > that one has trouble using multiple other protocols if one also > uses a protocol with positional AddrBlks, and I'd be interested > to see a specific counter-example. >=20 It's not impossible. It's just a lot easier when using 5444. >>> Fourth, I think there are some noticeable problems with RFC 5444 >>> that need fixing, but I have avoided making that into part of the >>> discussion about reactive protocols.=20 >>=20 >> Unless you are willing to make the arguments, please don't spread such mi= sinformation. >=20 > O.K. I'll bookmark your challenge and get back to it next month. >=20 >>=20 >>> For now, the task is to make >>> RFC 5444 serve the purpose which it is mandated to serve. That has >>> proved difficult enough.=20 >>=20 >> This is wrong. >=20 > Well, Ian spent a lot of time on it but couldn't do it so "easily". > I don't consider myself a beginner, but I find it at minimum tedious > and at worst error-prone. But -- I'm getting better at it. When we designed LOADng, designing it to use RFC5444 was a very easy exercis= e. Neither tedious nor error-prone. And, it brought all the other benefits of RFC5444 usage also. Thomas >> A multitude of MANET protocols have been designed to use RFC5444, includi= ng reactive protocols, without any problems. >>=20 >> It's extremely easy, even, once one understands RFC5444. >=20 > See the above. If I am challenged to get testimonials to the > contrary from other people, then I'll have to wait. I'm not at > all interested in arguing about it, especially right now! I will > at least say that other software developers seem more willing > to accept feedback. > --=20 > Regards, > Charlie P. --Apple-Mail-2DCA682B-5D89-4686-8981-23238D3C8D5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 21 janv. 2013, at 22:03, "Charles E. Perkins" <charliep@computer.org> wrote:

On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote:


On 21 janv. 2013, at 18:33, "Charles E. Perkins" <charliep@computer.org> wrote:

Hello Ulrich,

First, let's agree that, all other things being equal, position independence
is better than positional dependence.  Then, it's a matter of trading off
that positive feature versus other potential negatives.  In the extreme,
no one would add a kilobyte to the header just to preserve position
independence.

Reductio ad absurdum.

Usually, the phrase "Reductio ad absurdum." is followed by QED.


Next, please observe that Henning has proposed a change to RteMsg
design that offers positional independence.  I hope to write it up today
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the same
parser is, in my view, not a factor that should determine the outcome
of this design decision. 

That is, then, because you have not been in the business of implementing protocols and multi-protocol MANET routers. It is a HUGE benefit to be able to share parsing code, especially given that 5444 is (if used properly) both flexible, efficient to parse and efficient in encoding messages. It also gives you some nice benefits of running multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on the same device.

So you'd rather optimize for parser development time over
battery lifetime? 

You assert that they're different?

I've not observed the negative effects you describe above in real (battery constrained) deployments.

  At the beginning of my earlier email, I
referred to "tradeoffs".  I'll stand by that.  I dispute the notion
that one has trouble using multiple other protocols if one also
uses a protocol with positional AddrBlks, and I'd be interested
to see a specific counter-example.


It's not impossible.
It's just a lot easier when using 5444.

Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols. 

Unless you are willing to make the arguments, please don't spread such misinformation.

O.K.  I'll bookmark your challenge and get back to it next month.


For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has
proved difficult enough. 

This is wrong.

Well, Ian spent a lot of time on it but couldn't do it so "easily".
I don't consider myself a beginner, but I find it at minimum tedious
and at worst error-prone.  But -- I'm getting better at it.

When we designed LOADng, designing it to use RFC5444 was a very easy exercise. Neither tedious nor error-prone.

And, it brought all the other benefits of RFC5444 usage also.

Thomas

A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

See the above.  If I am challenged to get testimonials to the
contrary from other people, then I'll have to wait.   I'm not at
all interested in arguing about it, especially right now!   I will
at least say that other software developers seem more willing
to accept feedback.

-- 
Regards,
Charlie P.
--Apple-Mail-2DCA682B-5D89-4686-8981-23238D3C8D5F-- From charliep@computer.org Mon Jan 21 13:22:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33B21F8645 for ; Mon, 21 Jan 2013 13:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjgd7hjjP2lT for ; Mon, 21 Jan 2013 13:22:31 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 20F0221F8632 for ; Mon, 21 Jan 2013 13:22:31 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxOp3-0007aS-W2; Mon, 21 Jan 2013 16:22:30 -0500 Message-ID: <50FDB18D.5080302@computer.org> Date: Mon, 21 Jan 2013 13:22:21 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8629b422cea81c30d4eb2a1559f078b564350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 21:22:32 -0000 Hello Uli, On 1/21/2013 1:16 PM, Ulrich Herberg wrote: > > > When I changed our LOADng implementation from a fixed packet format to > RFC5444, it did not take me more than two days (that includes > implementing RFC5444). I did not think it was hard. And it was not > error-prone, as shown by an interop test that I did soon after that > update, which was very successful after only little time fixing > minimal bugs. Therefore, I cannot confirm that it is "tedious" or > "error-prone". This is good news. I think you truly qualify as an expert at RFC 5444. I reckon I also will be an expert before long. -- Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Tue Jan 22 05:50:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7157621F894E for ; Tue, 22 Jan 2013 05:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwniw7NO+O+d for ; Tue, 22 Jan 2013 05:50:57 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6624921F8949 for ; Tue, 22 Jan 2013 05:50:56 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxeFb-0002w2-1F for manet@ietf.org; Tue, 22 Jan 2013 14:50:55 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxeFa-0000sj-Us for manet@ietf.org; Tue, 22 Jan 2013 14:50:54 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Jan 2013 14:50:54 +0100 Message-ID: <50FE9934.7070009@fkie.fraunhofer.de> Date: Tue, 22 Jan 2013 14:50:44 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> In-Reply-To: <50FDAD22.7080706@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030607050902050809080201" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16549/Tue Jan 22 13:22:44 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 13:50:58 -0000 --------------ms030607050902050809080201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/21/2013 10:03 PM, Charles E. Perkins wrote: > On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote: >> That is, then, because you have not been in the business of >> implementing protocols and multi-protocol MANET routers. It is a HUGE >> benefit to be able to share parsing code, especially given that 5444 >> is (if used properly) both flexible, efficient to parse and efficient >> in encoding messages. It also gives you some nice benefits of running >> multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on >> the same device. > > So you'd rather optimize for parser development time over > battery lifetime? At the beginning of my earlier email, I > referred to "tradeoffs". I'll stand by that. I dispute the notion > that one has trouble using multiple other protocols if one also > uses a protocol with positional AddrBlks, and I'd be interested > to see a specific counter-example. The trouble starts when you get two protocols with positional dependent=20 stuff. The solution is to stay with the T in TLV (its "type") and not=20 start hacking half of it away. Just imagine your suggestion with AODVv2 and another one that wants to=20 use the first address for something else. Or just a generator that wants = to reorder the constructed message addresses to get a better compression.= Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030607050902050809080201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjIxMzUwNTJaMCMGCSqGSIb3DQEJBDEWBBQJto3yEPyTZPK+wg6Qu/JVV+49rzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAvW4ml2q+B5yWPvMwJrBNW1gcCT13wqma9Evo8r7nmCvV ArA95bCQHGDwHYbn7a+5+moMGjHY5utzTyM3GfQv4GCD2RFy3Lkrt354gJAVPe/Hk4dGOejG yV40fWdTpl4XYyl4fsU7H56tvFyu2tggqTKgrVpFl7pn7YaCQLv8pIsufChEcpnEMqaTlJvu VJ+xECEflZ2y7CXUBtWHfJ0SegMP7QzgQ/27pvrZmCJGKplBPYzXXq7+yARx3kRQ3oMewVcr aya2FZjX0mXuh3c0HZ7BWTmK1PuBC2y3Dc7Ym27TV87PMBhRX0jL8shd0l56wOG8jy+7TnAv HIJ7rqPTrwAAAAAAAA== --------------ms030607050902050809080201-- From henning.rogge@fkie.fraunhofer.de Tue Jan 22 06:43:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFCF21F875C for ; Tue, 22 Jan 2013 06:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EkjE23gEqFe for ; Tue, 22 Jan 2013 06:43:29 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id E9D6D21F86C9 for ; Tue, 22 Jan 2013 06:43:28 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Txf4O-000347-BX; Tue, 22 Jan 2013 15:43:24 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Txf4O-0002HQ-8q; Tue, 22 Jan 2013 15:43:24 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Jan 2013 15:43:23 +0100 Message-ID: <50FEA587.1000006@fkie.fraunhofer.de> Date: Tue, 22 Jan 2013 15:43:19 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles E. Perkins" References: <50FD9E4A.7010807@computer.org> In-Reply-To: <50FD9E4A.7010807@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030504060101010907000004" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16549/Tue Jan 22 13:22:44 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:43:30 -0000 --------------ms030504060101010907000004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/21/2013 09:00 PM, Charles E. Perkins wrote: > I propose to replace the existing AODVv2 TLVs with the TLVs defined abo= ve, > and to move the positional-dependent SeqNum TLV to iRREP specification.= Even if it costs us a few bytes (I forgot about one type of TLV=20 compression), I suggest not doing this. We are adding information without any type or attribute to a type based=20 format. We are wasting a lot of potential of the format with this. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030504060101010907000004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjIxNDQzMjFaMCMGCSqGSIb3DQEJBDEWBBQxbniQdbtqrfvDhdtHOyHplUUEEzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAhcNiCv/ClmaJJWncDe5WrKyq2ZvTabUJstk8fFe92sKg efVh4/qp8BVxTSe6hgfZnhuWjmAzKGpJCsRbkFVORSQueNij4vb8GDeAXHRK5mb4Y5ZHkwmB mRHtXaCUrN4q5OGdgKjSIudwcigtmfNvhCnhKOr+wjWjq+IDPiyncx1aOgqItbC6diQAYQcF PQOQphhllHFbH5HdbKYRgOa/2M/4WapQnfK+V8gNMqx0/1yJrS2+6UNvCZsCznsecga0uLsL xLczUKUkt5gWSZtlYA0TaMBuVBftbWxLMI9fpS+uruigqY14d0lNh9EtKPkWOmUrHfbP6wiG pqe4XxKx0wAAAAAAAA== --------------ms030504060101010907000004-- From ietf@thomasclausen.org Tue Jan 22 07:18:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C9221F89B9 for ; Tue, 22 Jan 2013 07:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lptFhLWeS+1J for ; Tue, 22 Jan 2013 07:18:47 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC921F8949 for ; Tue, 22 Jan 2013 07:18:47 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 64172A3755 for ; Tue, 22 Jan 2013 07:18:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 34E211C0C53; Tue, 22 Jan 2013 07:18:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.67.12.134] (37-8-160-125.coucou-networks.fr [37.8.160.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B90361C0522; Tue, 22 Jan 2013 07:18:44 -0800 (PST) References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: <50FEA587.1000006@fkie.fraunhofer.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A551) From: Thomas Heide Clausen Date: Tue, 22 Jan 2013 16:18:41 +0100 To: Henning Rogge Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:18:48 -0000 Agree w. Henning.=20 --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 22 janv. 2013, at 15:43, Henning Rogge = wrote: > On 01/21/2013 09:00 PM, Charles E. Perkins wrote: >=20 >> I propose to replace the existing AODVv2 TLVs with the TLVs defined above= , >> and to move the positional-dependent SeqNum TLV to iRREP specification. >=20 > Even if it costs us a few bytes (I forgot about one type of TLV compressio= n), I suggest not doing this. >=20 > We are adding information without any type or attribute to a type based fo= rmat. We are wasting a lot of potential of the format with this. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Jan 22 07:42:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2388A21F8A4B for ; Tue, 22 Jan 2013 07:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQZ1pLxq0y3X for ; Tue, 22 Jan 2013 07:42:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC25C21F8A42 for ; Tue, 22 Jan 2013 07:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11588; q=dns/txt; s=iport; t=1358869323; x=1360078923; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yoPvRdIEqi0ocBKGJabpOVOcFaQ6RFWqssdTWQAtG70=; b=aRt8soDAPYXEh9+OiEqhyarhDr2AJDeSs3eBFV8iLyIydI29YuUOL3J4 Bz6ycn/r6RUdMWcF6F7mKVIQfw4HoOpjV2CsbDknZexAiX+RAyUyaa6my uzPk38zELuCM83iMyFoO/GxA1rv/ZQK6TCPqmd5HSt47dRV4+Ibv11Aa9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOey/lCtJXG//2dsb2JhbABEvjIWc4IfAQEEAQEBaAMJAhACAQgiHQcnCxQRAgQOBQiIEQysbI83BIx4BoNXYQOILJ4pgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,515,1355097600"; d="scan'208,217";a="166171031" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jan 2013 15:42:03 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0MFg3WY021466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 15:42:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 22 Jan 2013 09:42:02 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN81ribJtZ+zulZEq9CpdJ9dTPlZhLPgGAgAk6noCAADOEAIAAB0MAgAE4g4A= Date: Tue, 22 Jan 2013 15:42:02 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> In-Reply-To: <50FDAD22.7080706@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:42:05 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8xmbalnx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Charlie, Inline On Jan 21, 2013, at 4:03 PM, Charles E. Perkins wrote: On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote: On 21 janv. 2013, at 18:33, "Charles E. Perkins" > wrote: Hello Ulrich, First, let's agree that, all other things being equal, position independenc= e is better than positional dependence. Then, it's a matter of trading off that positive feature versus other potential negatives. In the extreme, no one would add a kilobyte to the header just to preserve position independence. Reductio ad absurdum. Usually, the phrase "Reductio ad absurdum." is followed by QED. Next, please observe that Henning has proposed a change to RteMsg design that offers positional independence. I hope to write it up today for evaluation. Third, we have lots of experience with positional dependent designs that are extensible -- not related to [manet]. To me this is almost a no-brainer, but I also know that the RFC 5444 (and, perhaps more inclusively, the XML) experts have relevant experience. Using the same parser is, in my view, not a factor that should determine the outcome of this design decision. That is, then, because you have not been in the business of implementing pr= otocols and multi-protocol MANET routers. It is a HUGE benefit to be able t= o share parsing code, especially given that 5444 is (if used properly) both= flexible, efficient to parse and efficient in encoding messages. It also g= ives you some nice benefits of running multiple protocols jointly (as is th= e case with NHDP/OLSRv2/SMF) on the same device. So you'd rather optimize for parser development time over battery lifetime? At the beginning of my earlier email, I referred to "tradeoffs". I'll stand by that. I dispute the notion that one has trouble using multiple other protocols if one also uses a protocol with positional AddrBlks, and I'd be interested to see a specific counter-example. For me, the issue here is that working group consensus seems to have solidi= fied around positional independence. If fact, Charlie, you seem to be the o= nly one holding the counter position. Based on Adrian's email on the way fo= rward, the specification needs to reflect the consensus of the WG. As of ri= ght now, that means it (the spec) needs to change. To the WG participants: If you are holding other views, now is the time to = express them. Fourth, I think there are some noticeable problems with RFC 5444 that need fixing, but I have avoided making that into part of the discussion about reactive protocols. Unless you are willing to make the arguments, please don't spread such misi= nformation. O.K. I'll bookmark your challenge and get back to it next month. Well, this worries me. At a minimum, I'd like to have the opportunity of un= derstanding the issues you allude to. Because at this point, I don't know h= ow to classify - is this in the "minor irritant" category, the "major pain = in the backside" column, or the "no way on Earth this will ever work" type?= You can't just lob something like this out and then keep on going, without= more information for the rest of us. Regards, Stan For now, the task is to make RFC 5444 serve the purpose which it is mandated to serve. That has proved difficult enough. This is wrong. Well, Ian spent a lot of time on it but couldn't do it so "easily". I don't consider myself a beginner, but I find it at minimum tedious and at worst error-prone. But -- I'm getting better at it. A multitude of MANET protocols have been designed to use RFC5444, including= reactive protocols, without any problems. It's extremely easy, even, once one understands RFC5444. See the above. If I am challenged to get testimonials to the contrary from other people, then I'll have to wait. I'm not at all interested in arguing about it, especially right now! I will at least say that other software developers seem more willing to accept feedback. -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8xmbalnx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <778F6F8C88F87545BF08615FAE2CC31E@cisco.com> Content-Transfer-Encoding: quoted-printable Charlie, 

Inline

On Jan 21, 2013, at 4:03 PM, Charles E. Perkins wrote:

On 1/21/2013 12:37 PM, Thomas Heide Clausen = wrote:


On 21 janv. 2013, at 18:33, "Charles E. Perkins" <charliep@computer.org= > wrote:

Hello Ulrich,

First, let's agree that, all other things being equal, position independenc= e
is better than positional dependence.  Then, it's a matter of trading = off
that positive feature versus other potential negatives.  In the extrem= e,
no one would add a kilobyte to the header just to preserve position
independence.

Reductio ad absurdum.

Usually, the phrase "Reductio ad absurdum." is followed by QED.

Next, please observe that Henning has propos= ed a change to RteMsg
design that offers positional independence.  I hope to write it up tod= ay
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a=
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the sam= e
parser is, in my view, not a factor that should determine the outcome
of this design decision. 

That is, then, because you have not been in the business of implementi= ng protocols and multi-protocol MANET routers. It is a HUGE benefit to be a= ble to share parsing code, especially given that 5444 is (if used properly)= both flexible, efficient to parse and efficient in encoding messages. It also gives you some nice benefits o= f running multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) = on the same device.

So you'd rather optimize for parser development time over
battery lifetime?   At the beginning of my earlier email, I
referred to "tradeoffs".  I'll stand by that.  I disput= e the notion
that one has trouble using multiple other protocols if one also
uses a protocol with positional AddrBlks, and I'd be interested
to see a specific counter-example.


For me, the issue here is that working group consensus seems to have s= olidified around positional independence. If fact, Charlie, you seem to be = the only one holding the counter position. Based on Adrian's email on the w= ay forward, the specification needs to reflect the consensus of the WG. As of right now, that means it (the sp= ec) needs to change. 

To the WG participants: If you are holding other views, now is the tim= e to express them. 





Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols. 

Unless you are willing to make the arguments, please don't spread such= misinformation.

O.K.  I'll bookmark your challenge and get back to it next month.

Well, this worries me. At a minimum, I'd like to have the opportunity = of understanding the issues you allude to. Because at this point, I don't k= now how to classify - is this in the "minor irritant" category, t= he "major pain in the backside" column, or the "no way on Earth this will ever work" type? You can't just l= ob something like this out and then keep on going, without more information= for the rest of us. 

Regards,
Stan




For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has proved difficult enough. 

This is wrong.

Well, Ian spent a lot of time on it but couldn't do it so "easily"= ;.
I don't consider myself a beginner, but I find it at minimum tedious
and at worst error-prone.  But -- I'm getting better at it.



A multitude of MANET protocols have been designed to use RFC5444, incl= uding reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

See the above.  If I am challenged to get testimonials to the
contrary from other people, then I'll have to wait.   I'm not at<= br> all interested in arguing about it, especially right now!   I wil= l
at least say that other software developers seem more willing
to accept feedback.

--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8xmbalnx03ciscoc_-- From abdussalambaryun@gmail.com Tue Jan 22 08:31:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CF021F8A79 for ; Tue, 22 Jan 2013 08:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGhb3-z2JZ6f for ; Tue, 22 Jan 2013 08:31:34 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6C61E21F8A6E for ; Tue, 22 Jan 2013 08:31:34 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id rr4so2246461pbb.41 for ; Tue, 22 Jan 2013 08:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YYB5mGXplFPtqtQZb/KdFWpdf7dU7xVAKr9ZoVGsfxM=; b=C+ihNqLIANC58vP3uF5qSPttk6kxJkcFRpXJxKDFBdQU3kwmNKkldIrK62MPxeyx2K n88jXEzx5AzG9uQ5al2CuUxxhb5q89vV8Dx+ypMy+VyTb57f6UeGHQzJydGh+l7fWPsd eaaBsZLX02yLNIxbySWaytwySI8FMUmIigqFiufXFUGHhq53NpXYGcf0uEzyH2Ws+0ws C6sE/A9OlOmtD7xd+zXwKV7MrA02HHRboIuME9yU8ScQSbu3dl4Rs8GvXqo7PtAxaysu qGv1PDSEPpm4hDToXIz7G7d1h3qgFRolP8yW+zEOeeu+XvUABLxCvdP0MFEnU4cVxCbk m97A== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr40698937pbc.70.1358872294102; Tue, 22 Jan 2013 08:31:34 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 08:31:33 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> Date: Tue, 22 Jan 2013 17:31:33 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:31:35 -0000 Dear Stan, Co-Chair of MANET WG Please don't ignore my input, I posted my opinion many times, :) I supported the reactive ideas of Mr.Perkins and agree with the draft-25. I reviewed the draft and gave comments, but how many have reviewed the work and gave suggestions to change with good reason for progress. I suggest/think that the coming process SHOULD be that the Chair of the WG submits the new WG draft-00 (was mentioned by AD), then we will be able to discuss more officially and reasonably. I am waiting for the chairs to inform us with the new editors so we can get work done. Please advise, AB On 1/22/13, Stan Ratliff (sratliff) wrote: > Charlie, > > Inline > > On Jan 21, 2013, at 4:03 PM, Charles E. Perkins wrote: > > On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote: > > > On 21 janv. 2013, at 18:33, "Charles E. Perkins" > > wrote: > > Hello Ulrich, > > First, let's agree that, all other things being equal, position > independence > is better than positional dependence. Then, it's a matter of trading off > that positive feature versus other potential negatives. In the extreme, > no one would add a kilobyte to the header just to preserve position > independence. > > Reductio ad absurdum. > > Usually, the phrase "Reductio ad absurdum." is followed by QED. > > > Next, please observe that Henning has proposed a change to RteMsg > design that offers positional independence. I hope to write it up today > for evaluation. > > Third, we have lots of experience with positional dependent designs > that are extensible -- not related to [manet]. To me this is almost a > no-brainer, but I also know that the RFC 5444 (and, perhaps more > inclusively, the XML) experts have relevant experience. Using the same > parser is, in my view, not a factor that should determine the outcome > of this design decision. > > That is, then, because you have not been in the business of implementing > protocols and multi-protocol MANET routers. It is a HUGE benefit to be able > to share parsing code, especially given that 5444 is (if used properly) both > flexible, efficient to parse and efficient in encoding messages. It also > gives you some nice benefits of running multiple protocols jointly (as is > the case with NHDP/OLSRv2/SMF) on the same device. > > So you'd rather optimize for parser development time over > battery lifetime? At the beginning of my earlier email, I > referred to "tradeoffs". I'll stand by that. I dispute the notion > that one has trouble using multiple other protocols if one also > uses a protocol with positional AddrBlks, and I'd be interested > to see a specific counter-example. > > > For me, the issue here is that working group consensus seems to have > solidified around positional independence. If fact, Charlie, you seem to be > the only one holding the counter position. Based on Adrian's email on the > way forward, the specification needs to reflect the consensus of the WG. As > of right now, that means it (the spec) needs to change. > > To the WG participants: If you are holding other views, now is the time to > express them. > > > > > > Fourth, I think there are some noticeable problems with RFC 5444 > that need fixing, but I have avoided making that into part of the > discussion about reactive protocols. > > Unless you are willing to make the arguments, please don't spread such > misinformation. > > O.K. I'll bookmark your challenge and get back to it next month. > > Well, this worries me. At a minimum, I'd like to have the opportunity of > understanding the issues you allude to. Because at this point, I don't know > how to classify - is this in the "minor irritant" category, the "major pain > in the backside" column, or the "no way on Earth this will ever work" type? > You can't just lob something like this out and then keep on going, without > more information for the rest of us. > > Regards, > Stan > > > > > For now, the task is to make > RFC 5444 serve the purpose which it is mandated to serve. That has > proved difficult enough. > > This is wrong. > > Well, Ian spent a lot of time on it but couldn't do it so "easily". > I don't consider myself a beginner, but I find it at minimum tedious > and at worst error-prone. But -- I'm getting better at it. > > > > A multitude of MANET protocols have been designed to use RFC5444, including > reactive protocols, without any problems. > > It's extremely easy, even, once one understands RFC5444. > > See the above. If I am challenged to get testimonials to the > contrary from other people, then I'll have to wait. I'm not at > all interested in arguing about it, especially right now! I will > at least say that other software developers seem more willing > to accept feedback. > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From hrogge@googlemail.com Tue Jan 22 08:41:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BA221F89D5 for ; Tue, 22 Jan 2013 08:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtnhvieHEg92 for ; Tue, 22 Jan 2013 08:41:29 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id E810721F89C3 for ; Tue, 22 Jan 2013 08:41:28 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so751269lbo.38 for ; Tue, 22 Jan 2013 08:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=43zM3woLCa6GTyDBxrmkbNbVpXNZSIn8+tZOmF4raiU=; b=dRTINf3rmC2l0j+qFcCztbEMkjvYRphtAjmWf2lnuvCRTL1Ir+mcw+Z1OJUJP6a2tm kijkhKOYF8SYVOnwC2uEUh7XagiA83Xx0WaxU/zAhNggqDYC7WwH/tCmVeFHSFk3IDko d1FpFYB4uGBUfqIMpbBudsXju/cOUiNuBdqeYAb+ZDtuvltT3cn7+7llcvvSo7NmMDkN UI0xOleLHPRU1smdLmfHmI8gck4WtH1xrJWiZoZf1579LJqNepMDNBZXaKE3AbW/eL9z K8iLSUpB7KVSQJIOp5xuNi13JGTAJBBGNUsB7/LKuMl7e2ZfmM1AZLScipmLjCSuhUsS 0S8w== X-Received: by 10.152.113.165 with SMTP id iz5mr22018955lab.50.1358872887804; Tue, 22 Jan 2013 08:41:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 22 Jan 2013 08:41:07 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Tue, 22 Jan 2013 17:41:07 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:41:30 -0000 On Tue, Jan 22, 2013 at 5:31 PM, Abdussalam Baryun wrote: > I suggest/think that the coming process SHOULD be that the Chair of > the WG submits the new WG draft-00 (was mentioned by AD), then we will > be able to discuss more officially and reasonably. I am waiting for > the chairs to inform us with the new editors so we can get work done. > Please advise, I do not think changing the name of the draft will do ANYTHING AT ALL to this discussion. Looking back into the history of MANET, one protocol already "got burned" for a "too small" attempt in allowing future extensions... OLSR (v1). It has a "message in packet" structure and it allowed new kind of messages. But the structure of the Hello/TC message itself proved to be a roadblock for the protocol because it couldn't be extended for link metrics. Both the NRL and the Olsr.org team had to create their own custom message type to implement an ETX metric (and making the protocol usable in practice), which broke any compatibility. So we have to be careful with this. Making all information in RFC5444 based protocols depend on TLVs (and not on position or the absence of TLVs) allows a nearly trivial merge of new ideas into existing protocol messages. As long as the TLV numbers do not collide, you can add whatever/wherever you want without breaking the original protocol. I think a lot of the current conflict is based on the decision how much we should base the protocol DESIGN on the necessary efficiency of some/many DEPLOYMENTS. I think we can resolve this conflict without a compromise differently. I will try to do a mail about this "transparent schema-based compression" I have been talking about tomorrow, maybe this can defuse parts of the tension in this discussion. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Tue Jan 22 08:52:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7142D21F8A54 for ; Tue, 22 Jan 2013 08:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chIeDgVEIxTq for ; Tue, 22 Jan 2013 08:52:12 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEE21F8A51 for ; Tue, 22 Jan 2013 08:52:12 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id fa1so4162464pad.35 for ; Tue, 22 Jan 2013 08:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3s9C4ZLcb0MhKydYHcczm8v5BNke68CGJcIQQvt8Mlo=; b=Kwfw3hNUqBSlo0ZBDgDrKVyacwp723wbEXJqjDu6j+BqierA0By+dk4FkihSVFdRcD XsspfR3tG4np95mDa6JNRj76LbWyiy5hNRvRRtdJXXjxkOrFuYn4gZBdH9CMhsptRNQ+ bZUFnEVGXxDJS1/i6BjnkBh4IqJzVe8STk8CIhfNiGWxJELH5RsoT+E3n84ouTUbB/TH PFMVzl0ad86rZXPWCh0zLk8/+pRDVIADf2QyiMwswS21W07ek0bBS/8eYtMqbTn1qkoO ZhK4sB4Jc5ry+ZlKy5PQ7B3UN6QYZb9YgMOIe1uz1d2sEXzs5JdPt+rgx97Uk/y/6GVE Biew== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr40878788pbc.20.1358873532420; Tue, 22 Jan 2013 08:52:12 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 08:52:11 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> Date: Tue, 22 Jan 2013 17:52:11 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:52:15 -0000 Hi Henning it was not me to make the rules of how we discuss things, but I understood that we need to follow in the new draft reactive protocol as it will be starting with draft-00 and we use track tools to input suggestions and progress. However, we can discuss any draft published and current alive, parked or died, but is that the draft that it is the work in progress of the WG, this is my concern, AB On 1/22/13, Henning Rogge wrote: > On Tue, Jan 22, 2013 at 5:31 PM, Abdussalam Baryun > wrote: >> I suggest/think that the coming process SHOULD be that the Chair of >> the WG submits the new WG draft-00 (was mentioned by AD), then we will >> be able to discuss more officially and reasonably. I am waiting for >> the chairs to inform us with the new editors so we can get work done. >> Please advise, > > I do not think changing the name of the draft will do ANYTHING AT ALL > to this discussion. > > Looking back into the history of MANET, one protocol already "got > burned" for a "too small" attempt in allowing future extensions... > OLSR (v1). > > It has a "message in packet" structure and it allowed new kind of > messages. But the structure of the Hello/TC message itself proved to > be a roadblock for the protocol because it couldn't be extended for > link metrics. Both the NRL and the Olsr.org team had to create their > own custom message type to implement an ETX metric (and making the > protocol usable in practice), which broke any compatibility. So we > have to be careful with this. > > Making all information in RFC5444 based protocols depend on TLVs (and > not on position or the absence of TLVs) allows a nearly trivial merge > of new ideas into existing protocol messages. As long as the TLV > numbers do not collide, you can add whatever/wherever you want without > breaking the original protocol. > > I think a lot of the current conflict is based on the decision how > much we should base the protocol DESIGN on the necessary efficiency of > some/many DEPLOYMENTS. I think we can resolve this conflict without a > compromise differently. > > I will try to do a mail about this "transparent schema-based > compression" I have been talking about tomorrow, maybe this can defuse > parts of the tension in this discussion. > > Henning Rogge > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > From abdussalambaryun@gmail.com Tue Jan 22 09:00:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD921F8818 for ; Tue, 22 Jan 2013 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5NJ3z166iMO for ; Tue, 22 Jan 2013 09:00:11 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6B21F86A6 for ; Tue, 22 Jan 2013 09:00:10 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so3341939dal.29 for ; Tue, 22 Jan 2013 09:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H3wkuDOVwNQ05B3zNTEuNjivRHFalxcVuFxZ1D1W0Tk=; b=k1PCPP+gFLq3mJPiDalxqg2BgPKbm0U5W6IPQFr2i4gY+rg9DACNBgsK6m5cx+7eX/ 1FpSSziiFkNkVv29eBLmSK7wUUiNtAEFq5PjXJlulFoJHKbuL4vOb3ipymOPTUDmL1Qj o6gyJOELeckxkrtwQIPZQF0nQ+G6MqE2Gt1jQHA7H7tBYm+kWPhZtwEOe/2wMYJthOSU RWmHFKFQwjkSJLDwEGObG8fhEPA8lw3p82AVVUEdcPbpdTw/AfztDwuF68bvTLcIukaE jDuPJ9pvq7PtmAYqbdMAOTunZttEaUsWEFXn5Ptkj8UE6Pq7VAsq4zoAsW9/yg1TLnRU Tgvg== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr40953415pbc.70.1358874010514; Tue, 22 Jan 2013 09:00:10 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 09:00:10 -0800 (PST) In-Reply-To: <024001cdf286$d01a81f0$704f85d0$@olddog.co.uk> References: <024001cdf286$d01a81f0$704f85d0$@olddog.co.uk> Date: Tue, 22 Jan 2013 18:00:10 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Decision on Reactive Protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:00:13 -0000 Hi Adrian, I thank you for this email. I understand that the new WG draft-ietf-manet-00 will be submitted actively and editor team informed by the WG chairs. However, I will continue discussion ideas on the drafts available so far until I receive the draft-ietf-manet-aodv-v2-00.txt that you mentioned, thanking you AB On 1/14/13, Adrian Farrel wrote: > Hello MANET working group. > > Thank you to all the people (23) who expressed an opinion on or off the list > in > answer to my three questions. Thank you, too, to those of you who felt the > need > to give me more background on your thinking. > > It is overwhelmingly clear that the WG wants to find a way to pursue a > Reactive > Protocol. Very few of you said that removing Reactive from the charter was > something they would be happy with. So we will try to find a way to struggle > on > with the charter we have. > > A significant minority (roughly one in three), said they would be willing > to > progress two Experimental I-Ds in parallel within the working group. > However, > many of these people expressed reservations, preferences for variations, or > noted that this was a last resort in their view. Thus, although this is > clearly > the easiest option to the production of an RFC describing a Reactive > protocol, I > am also rejecting this option. Not an insignificant factor for me was the > observation that MANET has already produced an Experimental Reactive > protocol > and made the decision to move on with a Standards Track protocol. > > OK, so that means that we will work on a single Standards Track reactive > protocol, and I (oh, lucky me!) get to choose which document will form the > basis > of this work. I feel rather like the vicar announcing the results of the > beautiful baby competition - I know that the mothers of the babies that > don't > win will gouge my eyes out later in the cream tea tent. > > We will run with the current working group I-D (draft-ietf-manet-dymo), but > with > several significant caveats: > - The document will be renamed draft-ietf-manet-aodv-v2-00.txt > - The chairs will announce a new editor team > - I expect the new document to be rewritten/restructured as necessary > for readability and utility according to the demands of the WG > - I expect all people who provide text to be suitably credited > - Acknowledgments section for small pieces of text > - Contributing Author section for larger pieces of text > - I expect ideas and text to be freely taken from draft-clausen-loadng > with appropriate credit to the authors > - I expect the editors of the new draft to bow to WG consensus at all > times (even when they personally think the idea is wrong) > - I would not be surprised if the content of the document changed > radically over the next few revisions > > To achieve all this, the editor team will need to do more than hold the pen. > I > expect them to use the issue tracker system and to patiently work through > the > issues bringing them up for debate in small numbers so that everyone can > participate in the discussion without losing track of the issues. For the > editors, this will be as much a management challenge as a protocol design > task. > > I note that, when I asked my question, I made it clear that if this option > was > selected I would expect the whole working group to pull behind the single > draft. > That does not prevent anyone from raising their concerns about the > technical > direction and from suggesting alternative mechanisms and text. But it does > require that everyone gets behind the consensus when it emerges or is > called, > and it assumes that no-one will be disruptive to the working group process > in > producing the Standards Track document. > > I know there will be a huge temptation to debate this decision, express > dissatisfaction/disappointment, or raise new points that I might not have > considered. However, the decision is made and I hope the WG will now buckle > down > to the difficult job of pursuing the technical work using the normal tools > of > IETF debate and documentation. > > Please be aware that this is not the first time in the history of the IETF > that > a choice between documents has been necessary where no consensus could be > found. > In one case a coin was tossed to make the choice! AFAIK, in every case the > working group quickly got behind the decision and went ahead to make a > high-quality protocol specification. > > Thank you all for your patience during this decision process. As the chairs > and > I have all agreed, we (the three of us - and our predecessors) should have > stepped in and made decisions sooner. We are where we are, and I hope we can > now > move forward. > > Please look out for a further email from the chairs announcing the > editorial > team. > > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From sratliff@cisco.com Tue Jan 22 10:05:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26BB21F8A42 for ; Tue, 22 Jan 2013 10:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUXG1srP+rPg for ; Tue, 22 Jan 2013 10:05:46 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 04BED21F8A40 for ; Tue, 22 Jan 2013 10:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2609; q=dns/txt; s=iport; t=1358877946; x=1360087546; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xghtW/3FnGzEuYInDJWBaZyGvOGh6fT5Sv+Wr0E5tAw=; b=c6STlJFxjOoJBWKFy1q9C5dtc86UR1qgOUGmb56wO7AQ9cJM0ZAiB6bW nmG3DkMn7QaYckA1Lu3tev363MTvKoyq4H7Ljs9yZEa1KWJnKxjpCcKTl eWb0gqKYWLLjIRSV0oYGESBp+oNZvhxm2ijSY769F6dt2k2y8a1BiMTqh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADrU/lCtJV2b/2dsb2JhbABEvicWc4IeAQEBAwEBAQE3NAkCBQsCAQgOCgoUECEGCyUCBA4FCId/AwkGDK0ChkYNiVWMB4EHgntMYQOUNoJyihuFEoJ1gW81 X-IronPort-AV: E=Sophos;i="4.84,515,1355097600"; d="scan'208";a="163279909" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jan 2013 18:05:45 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0MI5jL3007101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 18:05:45 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 22 Jan 2013 12:05:45 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN81ribJtZ+zulZEq9CpdJ9dTPlZhLPgGAgAk6noCAADOEAIAAB0MAgAE4g4CAAA3XgIAAAqyAgAAXpAA= Date: Tue, 22 Jan 2013 18:05:44 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:05:46 -0000 On Jan 22, 2013, at 11:41 AM, Henning Rogge wrote: > On Tue, Jan 22, 2013 at 5:31 PM, Abdussalam Baryun > wrote: >> I suggest/think that the coming process SHOULD be that the Chair of >> the WG submits the new WG draft-00 (was mentioned by AD), then we will >> be able to discuss more officially and reasonably. I am waiting for >> the chairs to inform us with the new editors so we can get work done. >> Please advise, >=20 > I do not think changing the name of the draft will do ANYTHING AT ALL > to this discussion. +1 Abdussalam, my apology for appearing to ignore your opinion. Poor communica= tion on my part. However, that doesn't change my opinion at all - the rough= consensus of the WG is behind the notion of position independence for TLVs= in the reactive routing protocol.=20 Regards, Stan >=20 > Looking back into the history of MANET, one protocol already "got > burned" for a "too small" attempt in allowing future extensions... > OLSR (v1). >=20 > It has a "message in packet" structure and it allowed new kind of > messages. But the structure of the Hello/TC message itself proved to > be a roadblock for the protocol because it couldn't be extended for > link metrics. Both the NRL and the Olsr.org team had to create their > own custom message type to implement an ETX metric (and making the > protocol usable in practice), which broke any compatibility. So we > have to be careful with this. >=20 > Making all information in RFC5444 based protocols depend on TLVs (and > not on position or the absence of TLVs) allows a nearly trivial merge > of new ideas into existing protocol messages. As long as the TLV > numbers do not collide, you can add whatever/wherever you want without > breaking the original protocol. >=20 > I think a lot of the current conflict is based on the decision how > much we should base the protocol DESIGN on the necessary efficiency of > some/many DEPLOYMENTS. I think we can resolve this conflict without a > compromise differently. >=20 > I will try to do a mail about this "transparent schema-based > compression" I have been talking about tomorrow, maybe this can defuse > parts of the tension in this discussion. >=20 > Henning Rogge > --=20 > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Jan 22 10:22:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AAA21F875C for ; Tue, 22 Jan 2013 10:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9lDlU+pgKQq for ; Tue, 22 Jan 2013 10:22:42 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9337721F874B for ; Tue, 22 Jan 2013 10:22:41 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxiUa-000627-OD; Tue, 22 Jan 2013 13:22:40 -0500 Message-ID: <50FED8E7.9010106@computer.org> Date: Tue, 22 Jan 2013 10:22:31 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Henning Rogge References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> In-Reply-To: <50FEA587.1000006@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86930471fbc732785a56d82c58ec7619c9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:22:43 -0000 Hello Henning, On 1/22/2013 6:43 AM, Henning Rogge wrote: > On 01/21/2013 09:00 PM, Charles E. Perkins wrote: > >> I propose to replace the existing AODVv2 TLVs with the TLVs defined >> above, >> and to move the positional-dependent SeqNum TLV to iRREP specification. > > Even if it costs us a few bytes (I forgot about one type of TLV > compression), I suggest not doing this. Well, it's 7 bytes versus 12 bytes. > > We are adding information without any type or attribute to a type > based format. We are wasting a lot of potential of the format with this. I don't understand this. Implementations that don't need to save the space would certainly have the other alternatives available, right? Plus, I don't exactly understand your point about wasting the potential of "the format"...? Which format is being wasted? -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Jan 22 10:40:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8CC21F8A05 for ; Tue, 22 Jan 2013 10:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcyur-hf2p+5 for ; Tue, 22 Jan 2013 10:40:37 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9F21F89BA for ; Tue, 22 Jan 2013 10:40:37 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so2789185pbc.7 for ; Tue, 22 Jan 2013 10:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OEStmqjgvIfyZov8ytryIyQ4Ra+5jThO4qQsi9O9vOM=; b=JgMXG3MmMRU8J4YkdWdAewZfacfdi8V6nJP38Ca1vFDRh42ZpozA21h+sGnStff/oP 2muH457iFONVBglTOE7ni2H/DsrMXJdBsblKJmQ6olc2oDZX1TxDGIrv82k8UZoqvYbL OtuQRWWnnJTTUL8hORaBWA+xJqvgQzmg5a2bDczd8JbvySCNsP3Kd3CzlMAm1VkaYF5a sb+UoNCFjOf50kEsvFH0pPpHkFUdapGQj4iiUnOe4N2/931eyN6gVbyFSs+s0ENJMHOZ PBldp2N9ngz5PdBq/oy+rWRCV5N9RnRlC70TzTMZ5byQB1Ca/8j2Fp++WuM1nR6Yr1sw AjAw== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr41751320pbc.70.1358880036799; Tue, 22 Jan 2013 10:40:36 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 10:40:36 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> Date: Tue, 22 Jan 2013 19:40:36 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:40:38 -0000 Hi Stan, Thanks for your reply, I respect your opinion as well, In regards to the TLVs do you think the *protocol* performance is better if we use non-position TLV? That is the question, the reasons that some participants say of changing the message format are external reasons not related to the *protocol* performance, and does not answer the question. In my opinion they should answer so we can understand. I understand from your reply that you stand with numbers not core reasons. The discussions with ignoring the reactive protocol functions/performance are useless, IMO, that direction of ignoring the core function will not help in progress, AB On 1/22/13, Stan Ratliff (sratliff) wrote: > > On Jan 22, 2013, at 11:41 AM, Henning Rogge wrote: > >> On Tue, Jan 22, 2013 at 5:31 PM, Abdussalam Baryun >> wrote: >>> I suggest/think that the coming process SHOULD be that the Chair of >>> the WG submits the new WG draft-00 (was mentioned by AD), then we will >>> be able to discuss more officially and reasonably. I am waiting for >>> the chairs to inform us with the new editors so we can get work done. >>> Please advise, >> >> I do not think changing the name of the draft will do ANYTHING AT ALL >> to this discussion. > > +1 > > Abdussalam, my apology for appearing to ignore your opinion. Poor > communication on my part. However, that doesn't change my opinion at all - > the rough consensus of the WG is behind the notion of position independence > for TLVs in the reactive routing protocol. > > Regards, > Stan > > >> >> Looking back into the history of MANET, one protocol already "got >> burned" for a "too small" attempt in allowing future extensions... >> OLSR (v1). >> >> It has a "message in packet" structure and it allowed new kind of >> messages. But the structure of the Hello/TC message itself proved to >> be a roadblock for the protocol because it couldn't be extended for >> link metrics. Both the NRL and the Olsr.org team had to create their >> own custom message type to implement an ETX metric (and making the >> protocol usable in practice), which broke any compatibility. So we >> have to be careful with this. >> >> Making all information in RFC5444 based protocols depend on TLVs (and >> not on position or the absence of TLVs) allows a nearly trivial merge >> of new ideas into existing protocol messages. As long as the TLV >> numbers do not collide, you can add whatever/wherever you want without >> breaking the original protocol. >> >> I think a lot of the current conflict is based on the decision how >> much we should base the protocol DESIGN on the necessary efficiency of >> some/many DEPLOYMENTS. I think we can resolve this conflict without a >> compromise differently. >> >> I will try to do a mail about this "transparent schema-based >> compression" I have been talking about tomorrow, maybe this can defuse >> parts of the tension in this discussion. >> >> Henning Rogge >> -- >> We began as wanderers, and we are wanderers still. We have lingured >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Tue Jan 22 11:01:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7AB21F8A7B for ; Tue, 22 Jan 2013 11:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilRue08YH0-F for ; Tue, 22 Jan 2013 11:01:04 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8723621F8A3D for ; Tue, 22 Jan 2013 11:01:04 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so3378433dak.16 for ; Tue, 22 Jan 2013 11:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lLpHW2F6QISg9iHVQvCzdhmmAi09y52qgqNlT9MjKkc=; b=aZD1rVBLEiGL2DvkJ0gXmx7dRuevSFdn0CH81APfH2yukMdnMZCHa4KosZuUdNE6C6 IMOgRpLdamJHNnlDNfFzuOL5QjByhW4yb8QNAg1UkyH+vLctqTs2GncZPzxMGIt/ctqZ CP0lTgelgcs/dKyMtmqcSg3dUEMESoVYm6DCNTcB4YOpN2g3XkqaluDAvKDklQeb3XjO 17ddp3OkYzoegXCnem93NJ5OQPAJZ+2e298LDOObgrgjadBuejLDM8wAWXmbCYJ5aFFi E0p52HMi4Si6w8otAtIh2TBmRIs5Xd7v68ccMeeMZgiBasm/08KJSpbtqqXIA7lfEeLZ uwSA== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr41884335pbc.20.1358881264331; Tue, 22 Jan 2013 11:01:04 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 11:01:04 -0800 (PST) In-Reply-To: <50FED8E7.9010106@computer.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> Date: Tue, 22 Jan 2013 20:01:04 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:01:06 -0000 Hi Charlie, I did not understand your input proposal and Henning's input as well (what did he forget?). Your input did not say why you are changing that TLV, as I always like to know why we do things so we can relate our actions with reason so I can understand, also not sure what was exactly henning's proposal mentioned in main-post, because Henning had many on the list and this was a new thread. I expect I will have to study this change, not sure what to say. Regarding Hennings reply, he still not happy with TLV change because he wants to see the associated attribute of that information, maybe that is what he ment, AB On 1/22/13, Charles E. Perkins wrote: > Hello Henning, > > On 1/22/2013 6:43 AM, Henning Rogge wrote: >> On 01/21/2013 09:00 PM, Charles E. Perkins wrote: >> >>> I propose to replace the existing AODVv2 TLVs with the TLVs defined >>> above, >>> and to move the positional-dependent SeqNum TLV to iRREP specification. >> >> Even if it costs us a few bytes (I forgot about one type of TLV >> compression), I suggest not doing this. > > Well, it's 7 bytes versus 12 bytes. > >> >> We are adding information without any type or attribute to a type >> based format. We are wasting a lot of potential of the format with this. > > I don't understand this. Implementations that don't need to save the > space would certainly have the other alternatives available, right? > Plus, I don't exactly understand your point about wasting the potential > of "the format"...? Which format is being wasted? > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From sratliff@cisco.com Tue Jan 22 11:15:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5521F89AE for ; Tue, 22 Jan 2013 11:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC6HuIblAgvR for ; Tue, 22 Jan 2013 11:15:25 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F124C21F85C3 for ; Tue, 22 Jan 2013 11:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4524; q=dns/txt; s=iport; t=1358882125; x=1360091725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nMddXHJdTdLvkKs6PtI4WwmP1SoEvyAyi5fA7E8hxYE=; b=KLQcccx4foiVd4nFKBKWc6TGMDF5EoLapKFJkd5zxZ2qgLeV98IY3ZBf dpwWhRxDW/VIJVCQ6fH0lfFgIyWVqVlToMuBZHMWByDaH/LcKrhvUMxuM SrBVvPxM2d0GlBzSAstIYFzcUnmeMIMhBujH69kdEstpLwdpvaYf/z4jK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADjk/lCtJV2Z/2dsb2JhbABEvikWc4IeAQEBAwEBAQE3NAkCBQsCAQgYChQQIQYLJQIEDgUIh38DCQYMrGmGTQ2JVYwHgQeCe0xhA5Q2gnKKG4USgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,516,1355097600"; d="scan'208";a="163324088" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jan 2013 19:15:24 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0MJFOO6016311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 19:15:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 22 Jan 2013 13:15:24 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] Notifications from the IETF tools Issue Tracker Thread-Index: AQHN81ribJtZ+zulZEq9CpdJ9dTPlZhLPgGAgAk6noCAADOEAIAAB0MAgAE4g4CAAA3XgIAAAqyAgAAXpACAAAm+AIAACbiA Date: Tue, 22 Jan 2013 19:15:23 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> References: <50EDF2E7.3020105@computer.org> <50EE6F28.6040300@fkie.fraunhofer.de> <50EE70F0.2020604@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:15:26 -0000 AB,=20 On Jan 22, 2013, at 1:40 PM, Abdussalam Baryun wrote: > Hi Stan, >=20 > Thanks for your reply, I respect your opinion as well, >=20 > In regards to the TLVs do you think the *protocol* performance is > better if we use non-position TLV? That is the question, the reasons > that some participants say of changing the message format are external > reasons not related to the *protocol* performance, and does not answer > the question. In my opinion they should answer so we can understand. Yes, I'm concerned about overall performance with position independent TLVs= . Specifically, I worry about added complexity to handle position dependenc= e. That being said, I do understand the notion of providing context for TL= Vs - that's the whole idea behind the DLEP message structure. The DLEP mess= age provides the context (e.g. the radio neighbor, and/or the specific far-= end neighbor); all TLVs are processed *within that context*.=20 So I'm advocating for TLVs being as atomic in nature as is possible, since = that would produce (IMO) higher-quality, better-performing implementations = than something that is position-dependent. It also allows for modularity (h= ence, code-sharing) of the parsers involved.=20 Regards, Stan >=20 > I understand from your reply that you stand with numbers not core > reasons. The discussions with ignoring the reactive protocol > functions/performance are useless, IMO, that direction of ignoring the > core function will not help in progress, >=20 > AB >=20 > On 1/22/13, Stan Ratliff (sratliff) wrote: >>=20 >> On Jan 22, 2013, at 11:41 AM, Henning Rogge wrote: >>=20 >>> On Tue, Jan 22, 2013 at 5:31 PM, Abdussalam Baryun >>> wrote: >>>> I suggest/think that the coming process SHOULD be that the Chair of >>>> the WG submits the new WG draft-00 (was mentioned by AD), then we will >>>> be able to discuss more officially and reasonably. I am waiting for >>>> the chairs to inform us with the new editors so we can get work done. >>>> Please advise, >>>=20 >>> I do not think changing the name of the draft will do ANYTHING AT ALL >>> to this discussion. >>=20 >> +1 >>=20 >> Abdussalam, my apology for appearing to ignore your opinion. Poor >> communication on my part. However, that doesn't change my opinion at all= - >> the rough consensus of the WG is behind the notion of position independe= nce >> for TLVs in the reactive routing protocol. >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> Looking back into the history of MANET, one protocol already "got >>> burned" for a "too small" attempt in allowing future extensions... >>> OLSR (v1). >>>=20 >>> It has a "message in packet" structure and it allowed new kind of >>> messages. But the structure of the Hello/TC message itself proved to >>> be a roadblock for the protocol because it couldn't be extended for >>> link metrics. Both the NRL and the Olsr.org team had to create their >>> own custom message type to implement an ETX metric (and making the >>> protocol usable in practice), which broke any compatibility. So we >>> have to be careful with this. >>>=20 >>> Making all information in RFC5444 based protocols depend on TLVs (and >>> not on position or the absence of TLVs) allows a nearly trivial merge >>> of new ideas into existing protocol messages. As long as the TLV >>> numbers do not collide, you can add whatever/wherever you want without >>> breaking the original protocol. >>>=20 >>> I think a lot of the current conflict is based on the decision how >>> much we should base the protocol DESIGN on the necessary efficiency of >>> some/many DEPLOYMENTS. I think we can resolve this conflict without a >>> compromise differently. >>>=20 >>> I will try to do a mail about this "transparent schema-based >>> compression" I have been talking about tomorrow, maybe this can defuse >>> parts of the tension in this discussion. >>>=20 >>> Henning Rogge >>> -- >>> We began as wanderers, and we are wanderers still. We have lingured >>> long enough on the shores of the cosmic ocean. We are ready at last to >>> set sail for the stars - Carl Sagan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Jan 22 11:32:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD3321F87C8 for ; Tue, 22 Jan 2013 11:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ-vCNrGPHcm for ; Tue, 22 Jan 2013 11:32:27 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0F21F877B for ; Tue, 22 Jan 2013 11:32:27 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Txja6-0001kK-Dr; Tue, 22 Jan 2013 14:32:26 -0500 Message-ID: <50FEE940.6060402@computer.org> Date: Tue, 22 Jan 2013 11:32:16 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <50EDF2E7.3020105@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ca8ce89f10ad645b235bf55e62c60326350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:32:27 -0000 Hello Stan, RFC 5444 AddrTLVs are "positionally dependent" on the order of the addresses in the AddrBlk. In other words, for each address, there can be a specific TLV that refers to that address and no others. From that point of view, I want to understand better your statements: On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: > Yes, I'm concerned about overall performance with position independent TLVs. Specifically, I worry about added complexity to handle position dependence. How is "performance" in the first sentence related to "complexity" in the second sentence? Usually, more complexity enables higher protocol performance, but at the cost of perhaps reduced parser development performance (not very likely to affect the performance of the parser). > So I'm advocating for TLVs being as atomic in nature as is possible I guess that, in this sentence, "atomic" means that one TLV block does not depend for the definition of its action on: - its position in the list of TLV blocks, or - whether or not another specific AddrTLV exists in the Address Block But these considerations are not related to whether or not the addresses in the AddrBlk are provided in any positionally dependent fashion. -- Regards, Charlie P. From ulrich@herberg.name Tue Jan 22 12:09:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9957D21F8B02 for ; Tue, 22 Jan 2013 12:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag-iuBeRlSGX for ; Tue, 22 Jan 2013 12:09:08 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3621F8AFE for ; Tue, 22 Jan 2013 12:09:08 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id n10so551592vcn.14 for ; Tue, 22 Jan 2013 12:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2vhiHjhdxdjHrnmrFf5/fAzYtVLcTjOXt4ll15hoag4=; b=HdHCpGnc4hm4H7tRXgK/UN+NbF8W4ZbOIv1blts9Osb/Ht/lixTwl9+DZRwnw4uy3f fuBmwphuXMwNM2URcH+qAmFO75wkUxY1toJY336y41sdEsnUSXgnnid5WSNnCocj3XjA OoLpGmHqCiYgTeFjV9Dtv/20k8ekRSdUMNe0I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2vhiHjhdxdjHrnmrFf5/fAzYtVLcTjOXt4ll15hoag4=; b=YB8xZoSCkZfjtPtkJ59GOewSj1QwG93bb6fErw5bZ4lGDAIh8zJMDTJgz1Vl12Egzv 7DCeo47px97fxlzYGu4LEQxIvgaEm8LeIyxbFkJ3n494tgMTOlxqzVgDVTG/N9bw5amW ix5e5vUxvgjmgLVaBnsgGcTuaLnmrnVPWchm3h0XvsmQbLJzz+LnRduFofydQWY4/kNC xPgWZhe6LiB4CEAefgATPBZa29q95gRyMIWFNYDsRAdovuU00jt0rJ5Dbs9rCl4jdzkv Y1+LUQU3lbzuH+AYdQgjkWf1oLwHQp1a4jWfUFbnUAY0BdfsQzunqoiI7LTfj32v4eOx kRng== MIME-Version: 1.0 X-Received: by 10.52.67.45 with SMTP id k13mr22871229vdt.9.1358885347493; Tue, 22 Jan 2013 12:09:07 -0800 (PST) Received: by 10.220.33.143 with HTTP; Tue, 22 Jan 2013 12:09:07 -0800 (PST) In-Reply-To: <50FEE940.6060402@computer.org> References: <50EDF2E7.3020105@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> Date: Tue, 22 Jan 2013 12:09:07 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf3071cd5c6d87ba04d3e626ca X-Gm-Message-State: ALoCoQlCY5EZANPCrpF8SfrT/oM/U247j0PJnvm0XgMVUhn9Ev6X7YBjyTWFpx3uK7LsPeuS9WZh Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:09:09 -0000 --20cf3071cd5c6d87ba04d3e626ca Content-Type: text/plain; charset=ISO-8859-1 Hello Charlie, On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins wrote: > > Hello Stan, > > RFC 5444 AddrTLVs are "positionally dependent" on the order of > the addresses in the AddrBlk. In other words, for each address, > there can be a specific TLV that refers to that address and > no others. > I am not quite sure that I understand you correctly. But if you are saying that only one TLV value can be associated with one particular address, this is not true. Multiple TLVs (and their values if they have one) can be associated with one address. There is a special case if multiple TLVs of the same type but different value are associated with the same address, which is mentioned in section 5.4.2. of RFC5444. In addition, one TLV value can be associated with multiple addresses (using the same value for each address, or in the case of a multivalue TLV with separated values per address, but in a single TLV) Best Ulrich > > From that point of view, I want to understand better your > statements: > > > On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: > >> Yes, I'm concerned about overall performance with position independent >> TLVs. Specifically, I worry about added complexity to handle position >> dependence. >> > > How is "performance" in the first sentence related to "complexity" in > the second sentence? Usually, more complexity enables higher protocol > performance, but at the cost of perhaps reduced parser development > performance (not very likely to affect the performance of the parser). > > > So I'm advocating for TLVs being as atomic in nature as is possible >> > > I guess that, in this sentence, "atomic" means that one TLV block > does not depend for the definition of its action on: > - its position in the list of TLV blocks, or > - whether or not another specific AddrTLV exists in the Address Block > > But these considerations are not related to whether or not the addresses > in the AddrBlk are provided in any positionally dependent fashion. > > -- > Regards, > Charlie P. > > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --20cf3071cd5c6d87ba04d3e626ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Charlie,

On Tue, Jan 22, 2013 at 11= :32 AM, Charles E. Perkins <charliep@computer.org> wrote= :

Hello Stan,

RFC 5444 AddrTLVs are "positionally dependent" on the order of the addresses in the AddrBlk. =A0In other words, for each address,
there can be a specific TLV <value> that refers to that address and no others.


I am not quite sure that I understa= nd you correctly. But if you are saying that only one TLV value can be asso= ciated with one particular address, this is not true. Multiple TLVs (and th= eir values if they have one) can be associated with one address. There is a= special case if multiple TLVs of the same type but different value are ass= ociated with the same address, which is mentioned in section 5.4.2. of RFC5= 444.
In addition, one TLV value can be associated with multiple addresses (using= the same value for each address, or in the case of a multivalue TLV with s= eparated values per address, but in a single TLV)

Best
Ulrich

=A0

>From that point of view, I want to understand better your
statements:


On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote:
Yes, I'm concerned about overall performance with position independent = TLVs. Specifically, I worry about added complexity to handle position depen= dence.

How is "performance" in the first sentence related to "compl= exity" in
the second sentence? =A0Usually, more complexity enables higher protocol performance, but at the cost of perhaps reduced parser development
performance (not very likely to affect the performance of the parser).


So I'm advocating for TLVs being as atomic in nature as is possible

I guess that, in this sentence, "atomic" means that one TLV block=
does not depend for the definition of its action on:
- its position in the list of TLV blocks, or
- whether or not another specific AddrTLV exists in the Address Block

But these considerations are not related to whether or not the addresses in the AddrBlk are provided in any positionally dependent fashion.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf3071cd5c6d87ba04d3e626ca-- From thomas@thomasclausen.org Tue Jan 22 12:13:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF9A21F8995 for ; Tue, 22 Jan 2013 12:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3JDwpJexS6Q for ; Tue, 22 Jan 2013 12:13:58 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id CE71321F8742 for ; Tue, 22 Jan 2013 12:13:58 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 8B8EA558F1D for ; Tue, 22 Jan 2013 12:13:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 52FB51CA851; Tue, 22 Jan 2013 12:13:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.75.234.180] (37-8-185-14.coucou-networks.fr [37.8.185.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E59601CA80B; Tue, 22 Jan 2013 12:13:56 -0800 (PST) References: <50EDF2E7.3020105@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE9 40.6060402@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-27947A52-AA48-478E-BB44-3BC49E1B94D5 Content-Transfer-Encoding: 7bit Message-Id: <70C2274C-6CA9-4639-93EC-B31BB09EBE9B@thomasclausen.org> X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Tue, 22 Jan 2013 21:13:52 +0100 To: Ulrich Herberg Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:13:59 -0000 --Apple-Mail-27947A52-AA48-478E-BB44-3BC49E1B94D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 22 janv. 2013, at 21:09, Ulrich Herberg wrote: > Hello Charlie, >=20 > On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins wrote: >>=20 >> Hello Stan, >>=20 >> RFC 5444 AddrTLVs are "positionally dependent" on the order of >> the addresses in the AddrBlk. In other words, for each address, >> there can be a specific TLV that refers to that address and >> no others. >=20 >=20 > I am not quite sure that I understand you correctly. But if you are saying= that only one TLV value can be associated with one particular address, this= is not true. Multiple TLVs (and their values if they have one) can be assoc= iated with one address. There is a special case if multiple TLVs of the same= type but different value are associated with the same address, which is men= tioned in section 5.4.2. of RFC5444.=20 > In addition, one TLV value can be associated with multiple addresses (usin= g the same value for each address, or in the case of a multivalue TLV with s= eparated values per address, but in a single TLV) >=20 And, none of that is "positionally dependent". Thomas > Best > Ulrich >=20 > =20 >>=20 >> =46rom that point of view, I want to understand better your >> statements: >>=20 >>=20 >> On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: >>> Yes, I'm concerned about overall performance with position independent T= LVs. Specifically, I worry about added complexity to handle position depende= nce. >>=20 >> How is "performance" in the first sentence related to "complexity" in >> the second sentence? Usually, more complexity enables higher protocol >> performance, but at the cost of perhaps reduced parser development >> performance (not very likely to affect the performance of the parser). >>=20 >>=20 >>> So I'm advocating for TLVs being as atomic in nature as is possible >>=20 >> I guess that, in this sentence, "atomic" means that one TLV block >> does not depend for the definition of its action on: >> - its position in the list of TLV blocks, or >> - whether or not another specific AddrTLV exists in the Address Block >>=20 >> But these considerations are not related to whether or not the addresses >> in the AddrBlk are provided in any positionally dependent fashion. >>=20 >> --=20 >> Regards, >> Charlie P. >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-27947A52-AA48-478E-BB44-3BC49E1B94D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 22 janv. 2013, at 21:09, Ulrich Her= berg <ulrich@herberg.name> w= rote:

Hello Charlie,
<= br>
On Tue, Jan 22, 2013 at 11:32 AM, Charles E. P= erkins <charliep@computer.org> wrote:

Hello Stan,

RFC 5444 AddrTLVs are "positionally dependent" on the order of
the addresses in the AddrBlk.  In other words, for each address,
there can be a specific TLV <value> that refers to that address and no others.


I am not quite sure that I understan= d you correctly. But if you are saying that only one TLV value can be associ= ated with one particular address, this is not true. Multiple TLVs (and their= values if they have one) can be associated with one address. There is a spe= cial case if multiple TLVs of the same type but different value are associat= ed with the same address, which is mentioned in section 5.4.2. of RFC5444. <= br> In addition, one TLV value can be associated with multiple addresses (using t= he same value for each address, or in the case of a multivalue TLV with sepa= rated values per address, but in a single TLV)


And, none of that is "positionally dependent".
<= br>
Thomas

Best
Ulrich

 

=46rom that point of view, I want to understand better your
statements:


On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote:
Yes, I'm concerned about overall performance with position independent TLVs.= Specifically, I worry about added complexity to handle position dependence.=

How is "performance" in the first sentence related to "complexity" in
the second sentence?  Usually, more complexity enables higher protocol<= br> performance, but at the cost of perhaps reduced parser development
performance (not very likely to affect the performance of the parser).


So I'm advocating for TLVs being as atomic in nature as is possible

I guess that, in this sentence, "atomic" means that one TLV block
does not depend for the definition of its action on:
- its position in the list of TLV blocks, or
- whether or not another specific AddrTLV exists in the Address Block

But these considerations are not related to whether or not the addresses
= in the AddrBlk are provided in any positionally dependent fashion.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-27947A52-AA48-478E-BB44-3BC49E1B94D5-- From abdussalambaryun@gmail.com Tue Jan 22 12:15:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7A521F8AFE for ; Tue, 22 Jan 2013 12:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq0-8-Y6d-nI for ; Tue, 22 Jan 2013 12:15:43 -0800 (PST) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD521F8AE3 for ; Tue, 22 Jan 2013 12:15:42 -0800 (PST) Received: by mail-da0-f45.google.com with SMTP id w4so3399172dam.18 for ; Tue, 22 Jan 2013 12:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o62VjyAJ0Qm3uvsVzznqHHB00qXbYCnN0C5R0CTqzQc=; b=kPEFxaUyF/MNGlPWLF9zmBxfOM52F2RdrrcGqkDrA9UPR0Vl258g/q+zGSLiCZeKaR 06q2U54n2ae6z0TzxDBQcRtkB4H8phYCdtH1W6h44KgC9FpaXUa9n4cWP9k7zT/R8usW EBV97D7+FkLlq9t7TgiEMWrwf06htHpj0CaxBVqTlmN+DDuzav+Q2oVCh6LmfdiEzUoQ bemY6iYvB8s0LIEs6HwpaXxRDFKhPTIEjgSNJtS9Y3kK4WBdu6AatnkFwsYMiN+QIP0w 6MYfMxhzE9s5S4ePSIjpWZtuMC/RyLN2lCr6WD8EeZQC/S9U9py0D4Vy0I1yxIiBGH1S c8bA== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr42536217pbb.43.1358885742670; Tue, 22 Jan 2013 12:15:42 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 12:15:42 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> Date: Tue, 22 Jan 2013 21:15:42 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:15:43 -0000 Your examples still applies to AODVv2, it can have multiple TLVs as well, AB On 1/22/13, Ulrich Herberg wrote: > Hello Charlie, > > On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins > wrote: > >> >> Hello Stan, >> >> RFC 5444 AddrTLVs are "positionally dependent" on the order of >> the addresses in the AddrBlk. In other words, for each address, >> there can be a specific TLV that refers to that address and >> no others. >> > > > I am not quite sure that I understand you correctly. But if you are saying > that only one TLV value can be associated with one particular address, this > is not true. Multiple TLVs (and their values if they have one) can be > associated with one address. There is a special case if multiple TLVs of > the same type but different value are associated with the same address, > which is mentioned in section 5.4.2. of RFC5444. > In addition, one TLV value can be associated with multiple addresses (using > the same value for each address, or in the case of a multivalue TLV with > separated values per address, but in a single TLV) > > Best > Ulrich > > > >> >> From that point of view, I want to understand better your >> statements: >> >> >> On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: >> >>> Yes, I'm concerned about overall performance with position independent >>> TLVs. Specifically, I worry about added complexity to handle position >>> dependence. >>> >> >> How is "performance" in the first sentence related to "complexity" in >> the second sentence? Usually, more complexity enables higher protocol >> performance, but at the cost of perhaps reduced parser development >> performance (not very likely to affect the performance of the parser). >> >> >> So I'm advocating for TLVs being as atomic in nature as is possible >>> >> >> I guess that, in this sentence, "atomic" means that one TLV block >> does not depend for the definition of its action on: >> - its position in the list of TLV blocks, or >> - whether or not another specific AddrTLV exists in the Address Block >> >> But these considerations are not related to whether or not the addresses >> in the AddrBlk are provided in any positionally dependent fashion. >> >> -- >> Regards, >> Charlie P. >> >> >> ______________________________**_________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/**listinfo/manet >> > From abdussalambaryun@gmail.com Tue Jan 22 12:19:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CA321F84FB for ; Tue, 22 Jan 2013 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMo74L66XGML for ; Tue, 22 Jan 2013 12:19:06 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89F21F84E9 for ; Tue, 22 Jan 2013 12:19:06 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id x6so3393032dac.12 for ; Tue, 22 Jan 2013 12:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=WfKj5YZ5Fg2TEX5BYKUAviWBxZ/VGJOjoZHVhc0DPo4=; b=csQBBEqFSP88AzLKG/+8NmZYr+vb5GQqbOBufFtvSoe/EuH9TO03CU8kAveudN8j2m 4gMcPPvA1YC/h3ghI3KqhNnSMdA3qKqpTEnC9THmHMC1j8IgV8kBbvcCWvVb98w92vxx 86l2bDjZTnLHDU/X2bG5m+F/6qIZS7Qwm0DnJLaY71OXwyCQVxBR/nRhGDuWbCiVYtCN jSc8nYOirmEeX2Pl+LNCtmY6KVjMswAUU0NDsGjs2Ac0P0EKpCzj5LiJq3ti2WFZL7IL pLGzLGIbaCXChrt9D6qBpz0yMhIT/f7rCR3Dz7Z3S276iXEwp8w8WEt+YJDqGq7CDZFh 7jYQ== MIME-Version: 1.0 X-Received: by 10.68.136.132 with SMTP id qa4mr42132994pbb.166.1358885945854; Tue, 22 Jan 2013 12:19:05 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 12:19:05 -0800 (PST) Date: Tue, 22 Jan 2013 21:19:05 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: [manet] Is it better to Request On-Demand and With-Position Info? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:19:06 -0000 Hi Stan, Ok I want to discuss issues related to performance as we mention, discussing inline; > Yes, I'm concerned about overall performance with position independent TLVs. > Specifically, I worry about added complexity to handle position dependence. > That being said, I do understand the notion of providing context for TLVs - > that's the whole idea behind the DLEP message structure. The DLEP message > provides the context (e.g. the radio neighbor, and/or the specific far-end > neighbor); all TLVs are processed *within that context*. The position independednt is good for communication context of discovering all neighbors or nodes, but what about a specific discovery, why we make it independent, while we are specific in our request. DLEP is similar discoverying all neighbors exchange, but AODV not similar tasks, > > So I'm advocating for TLVs being as atomic in nature as is possible, since > that would produce (IMO) higher-quality, better-performing implementations > than something that is position-dependent. It also allows for modularity > (hence, code-sharing) of the parsers involved. > I prefer we use both, but when needed the best, there are two kind of giving information or sending TLVs, On-Demand and Without-Demand if we are in a Without-Demand, then we can send TLVs Without-position, because it was Without-Demand, but if the information was On-Demand then we send TLVs With-position. If you want just to read all related info (as newspaper) without demand, then you can find what you want any time, but if you want a demanded information, you would prefered its format to be specified as requested. Please note that some nodes don't have time to read, and don't have your energy to read full newspaper ;) AB On 1/22/13, Stan Ratliff (sratliff) wrote: > AB, > > On Jan 22, 2013, at 1:40 PM, Abdussalam Baryun wrote: > >> Hi Stan, >> >> Thanks for your reply, I respect your opinion as well, >> >> In regards to the TLVs do you think the *protocol* performance is >> better if we use non-position TLV? That is the question, the reasons >> that some participants say of changing the message format are external >> reasons not related to the *protocol* performance, and does not answer >> the question. In my opinion they should answer so we can understand. > > Yes, I'm concerned about overall performance with position independent TLVs. > Specifically, I worry about added complexity to handle position dependence. > That being said, I do understand the notion of providing context for TLVs - > that's the whole idea behind the DLEP message structure. The DLEP message > provides the context (e.g. the radio neighbor, and/or the specific far-end > neighbor); all TLVs are processed *within that context*. > > So I'm advocating for TLVs being as atomic in nature as is possible, since > that would produce (IMO) higher-quality, better-performing implementations > than something that is position-dependent. It also allows for modularity > (hence, code-sharing) of the parsers involved. > > Regards, > Stan > > From hrogge@googlemail.com Tue Jan 22 12:19:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FAF21F84FB for ; Tue, 22 Jan 2013 12:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgz4AtVt895Z for ; Tue, 22 Jan 2013 12:19:07 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 052D721F84E9 for ; Tue, 22 Jan 2013 12:19:06 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ed20so3457379lab.16 for ; Tue, 22 Jan 2013 12:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Y9LeAt55Q5VekTu+s0yXW2ejL1tNSdHsBXhKBMYTj/0=; b=roYGXtrG+zVBFP68fv9velQg7zMgHSrXOXwYyKCTmx3aipqDF4VOy/TgSVaW5IPQDq YvthtNre52A23MM355MGPVxdNHoaywf4TI2zku8AsDOt/NgyiBGefMnny/hsoyuRpUyG MaaKen8W+0510TLCNfeg9+N9JEKSL0YgEsR9bDFOaqTlacSFeyax0MtLIqUyQk+bM8zx lOzD3U7YEwUmB6CBtP8nYSkKQVeRTAb5Txd8MsrEOO197JRmhSLtJNwJJ9tmpLZSiJtv a/q6jqawzthhGdr8PWH+PsxcXEKDMn+1R4aZv22aPLwsjGa6nQEdiE03n1E3+GVkw9rz JX0g== X-Received: by 10.152.123.34 with SMTP id lx2mr21368324lab.52.1358885945939; Tue, 22 Jan 2013 12:19:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Tue, 22 Jan 2013 12:18:45 -0800 (PST) In-Reply-To: <50FED8E7.9010106@computer.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> From: Henning Rogge Date: Tue, 22 Jan 2013 21:18:45 +0100 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:19:07 -0000 On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins wrote: > Hello Henning, >> Even if it costs us a few bytes (I forgot about one type of TLV >> compression), I suggest not doing this. > > Well, it's 7 bytes versus 12 bytes. No, it might be 49 vs. 54 bytes. Maybe the difference will be even less compared to the airtime the signal will use up. >> We are adding information without any type or attribute to a type based >> format. We are wasting a lot of potential of the format with this. > > I don't understand this. Implementations that don't need to save the > space would certainly have the other alternatives available, right? > Plus, I don't exactly understand your point about wasting the potential > of "the format"...? Which format is being wasted? The chance of building MANET protocols with a TLV format... you are throwing away parts of the advantages of a TLV format. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Tue Jan 22 12:22:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A342D21F84FB for ; Tue, 22 Jan 2013 12:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P50-DUWKuYwx for ; Tue, 22 Jan 2013 12:22:05 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74E21F86EF for ; Tue, 22 Jan 2013 12:22:05 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so3395391dae.31 for ; Tue, 22 Jan 2013 12:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ylEKlN1KTmjeHHoJLBnIoaURCZMBb7lFxSEsAT8tOhE=; b=N6LRoXlLHWSlL4LCEC+j22lELOF0Ws5VA4lwKTMfQ5Vqiv38EsH0YhHAZy/PGKsgAV meNPymBjMzxOhZvgOUZz1Lcz8kdecbTjhcu/7gK8NfdnkYaUVWFcALs6GniYpiWAl30u ORl7gcuTs7cA6lqfBoBbyQGJjGleWGKBodjrvC/rlEDSFAR5Qp++VO8OKD9+XjQiP/qV W6bkakIMfSAyl6tjRvM647EnKjOc7zZDZ51oNQXHDzA/xjNgWDEPmH7ICYCudCMZMGkB 7IhlbT09jelzv0CY7QFPKGo67kzOZmCf+E5aSScYDZGYbZhUVTR5rZrjwd0g/ZwKv/if r4ig== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr42466403pbc.20.1358886114292; Tue, 22 Jan 2013 12:21:54 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 12:21:54 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Jan 2013 21:21:54 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Is it better to Request On-Demand and With-Position Info? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:22:06 -0000 Forgot to mention that AODV is Ad hoc On-demand Routing, not Without-Demand AB On 1/22/13, Abdussalam Baryun wrote: > Hi Stan, > > Ok I want to discuss issues related to performance as we mention, > discussing inline; > >> Yes, I'm concerned about overall performance with position independent >> TLVs. >> Specifically, I worry about added complexity to handle position >> dependence. >> That being said, I do understand the notion of providing context for TLVs >> - >> that's the whole idea behind the DLEP message structure. The DLEP message >> provides the context (e.g. the radio neighbor, and/or the specific >> far-end >> neighbor); all TLVs are processed *within that context*. > > The position independednt is good for communication context of > discovering all neighbors or nodes, but what about a specific > discovery, why we make it independent, while we are specific in our > request. DLEP is similar discoverying all neighbors exchange, but AODV > not similar tasks, >> >> So I'm advocating for TLVs being as atomic in nature as is possible, >> since >> that would produce (IMO) higher-quality, better-performing >> implementations >> than something that is position-dependent. It also allows for modularity >> (hence, code-sharing) of the parsers involved. >> > > I prefer we use both, but when needed the best, there are two kind of > giving information or sending TLVs, On-Demand and Without-Demand if we > are in a Without-Demand, then we can send TLVs Without-position, > because it was Without-Demand, but if the information was On-Demand > then we send TLVs With-position. > > If you want just to read all related info (as newspaper) without > demand, then you can find what you want any time, but if you want a > demanded information, you would prefered its format to be specified as > requested. Please note that some nodes don't have time to read, and > don't have your energy to read full newspaper ;) > > AB > > On 1/22/13, Stan Ratliff (sratliff) wrote: >> AB, >> >> On Jan 22, 2013, at 1:40 PM, Abdussalam Baryun wrote: >> >>> Hi Stan, >>> >>> Thanks for your reply, I respect your opinion as well, >>> >>> In regards to the TLVs do you think the *protocol* performance is >>> better if we use non-position TLV? That is the question, the reasons >>> that some participants say of changing the message format are external >>> reasons not related to the *protocol* performance, and does not answer >>> the question. In my opinion they should answer so we can understand. >> >> Yes, I'm concerned about overall performance with position independent >> TLVs. >> Specifically, I worry about added complexity to handle position >> dependence. >> That being said, I do understand the notion of providing context for TLVs >> - >> that's the whole idea behind the DLEP message structure. The DLEP message >> provides the context (e.g. the radio neighbor, and/or the specific >> far-end >> neighbor); all TLVs are processed *within that context*. >> >> So I'm advocating for TLVs being as atomic in nature as is possible, >> since >> that would produce (IMO) higher-quality, better-performing >> implementations >> than something that is position-dependent. It also allows for modularity >> (hence, code-sharing) of the parsers involved. >> >> Regards, >> Stan >> >> > From abdussalambaryun@gmail.com Tue Jan 22 12:25:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61421F8A50 for ; Tue, 22 Jan 2013 12:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waaiEX0pyEQ4 for ; Tue, 22 Jan 2013 12:25:41 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9A321F86EF for ; Tue, 22 Jan 2013 12:25:41 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so4254592pad.38 for ; Tue, 22 Jan 2013 12:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z0nckeE3cfiNkWyJuUy8PpXKxyGG4eXxfsmtoVg9sEA=; b=aBSbfHYEbXqk2Qlgs/TA70Q8fHTow4c9a86NbdNbhbZKq+DDva3XTVR4QuQCGf84RW TIQa6QjpXRZzjqjoIdwCc8rCTAfaVMECegh6AeINHYWkG5tSDhK3ouS4u++jiUwzcDJ5 iEgLvwszBxCCd0HZ2ofS3zPug/DMu9zxIkwRSq0GwExgxTDi7qm0jD+foNuYWza0M/5d /2g5AnSceUO4b8iRCaXvcUOxp4w+2f5pOmAnQ2jHidS0tjvE7NsHAYA5YM1Jh9AQfeq8 XUijRRdHVGGoVjJb2p+k5zuaMTBU/PH8hS9nZLLhxAKDjr3xIYYM8jtJ3tdyA1TC/aeO bXJg== MIME-Version: 1.0 X-Received: by 10.66.78.100 with SMTP id a4mr59547833pax.4.1358886340717; Tue, 22 Jan 2013 12:25:40 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 12:25:40 -0800 (PST) In-Reply-To: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> Date: Tue, 22 Jan 2013 21:25:40 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:25:42 -0000 We don't need to send through all important information just demanded, because all potintial info may not be needed, we may use all resources we got. Did I miss your point, not sure, AB On 1/22/13, Henning Rogge wrote: > On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins > wrote: >> Hello Henning, >>> Even if it costs us a few bytes (I forgot about one type of TLV >>> compression), I suggest not doing this. >> >> Well, it's 7 bytes versus 12 bytes. > > No, it might be 49 vs. 54 bytes. Maybe the difference will be even > less compared to the airtime the signal will use up. > >>> We are adding information without any type or attribute to a type based >>> format. We are wasting a lot of potential of the format with this. >> >> I don't understand this. Implementations that don't need to save the >> space would certainly have the other alternatives available, right? >> Plus, I don't exactly understand your point about wasting the potential >> of "the format"...? Which format is being wasted? > > The chance of building MANET protocols with a TLV format... you are > throwing away parts of the advantages of a TLV format. > > Henning Rogge > > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From charliep@computer.org Tue Jan 22 12:47:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0192921F854E for ; Tue, 22 Jan 2013 12:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWoN7geqAncK for ; Tue, 22 Jan 2013 12:47:34 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id BA66921F84E4 for ; Tue, 22 Jan 2013 12:47:31 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Txkkk-0004Ir-Lu; Tue, 22 Jan 2013 15:47:30 -0500 Message-ID: <50FEFAD9.4020606@computer.org> Date: Tue, 22 Jan 2013 12:47:21 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: <50EDF2E7.3020105@computer.org> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010107040706040209050107" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861ff206d8e5e78bd5f1a65aa939df4648350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:47:35 -0000 This is a multi-part message in MIME format. --------------010107040706040209050107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Ulrich, Thanks for the clarification. I was aware that each address could have multiple TLV values applied, one each from different TLVs. I was trying to explain that, for each such TLV, there could be a distinct value applied per address. I think your explanation is better. Regards, Charlie P. On 1/22/2013 12:09 PM, Ulrich Herberg wrote: > Hello Charlie, > > On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins > > wrote: > > > Hello Stan, > > RFC 5444 AddrTLVs are "positionally dependent" on the order of > the addresses in the AddrBlk. In other words, for each address, > there can be a specific TLV that refers to that address and > no others. > > > > I am not quite sure that I understand you correctly. But if you are > saying that only one TLV value can be associated with one particular > address, this is not true. Multiple TLVs (and their values if they > have one) can be associated with one address. There is a special case > if multiple TLVs of the same type but different value are associated > with the same address, which is mentioned in section 5.4.2. of RFC5444. > In addition, one TLV value can be associated with multiple addresses > (using the same value for each address, or in the case of a multivalue > TLV with separated values per address, but in a single TLV) > > Best > Ulrich > > > >From that point of view, I want to understand better your > statements: > > > On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: > > Yes, I'm concerned about overall performance with position > independent TLVs. Specifically, I worry about added complexity > to handle position dependence. > > > How is "performance" in the first sentence related to "complexity" in > the second sentence? Usually, more complexity enables higher protocol > performance, but at the cost of perhaps reduced parser development > performance (not very likely to affect the performance of the > parser). > > > So I'm advocating for TLVs being as atomic in nature as is > possible > > > I guess that, in this sentence, "atomic" means that one TLV block > does not depend for the definition of its action on: > - its position in the list of TLV blocks, or > - whether or not another specific AddrTLV exists in the Address Block > > But these considerations are not related to whether or not the > addresses > in the AddrBlk are provided in any positionally dependent fashion. > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------010107040706040209050107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Ulrich,

Thanks for the clarification.  I was aware that each address could have
multiple TLV values applied, one each from different TLVs.  I was trying
to explain that, for each such TLV, there could be a distinct value applied
per address.  I think your explanation is better.

Regards,
Charlie P.


On 1/22/2013 12:09 PM, Ulrich Herberg wrote:
Hello Charlie,

On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins <charliep@computer.org> wrote:

Hello Stan,

RFC 5444 AddrTLVs are "positionally dependent" on the order of
the addresses in the AddrBlk.  In other words, for each address,
there can be a specific TLV <value> that refers to that address and
no others.


I am not quite sure that I understand you correctly. But if you are saying that only one TLV value can be associated with one particular address, this is not true. Multiple TLVs (and their values if they have one) can be associated with one address. There is a special case if multiple TLVs of the same type but different value are associated with the same address, which is mentioned in section 5.4.2. of RFC5444.
In addition, one TLV value can be associated with multiple addresses (using the same value for each address, or in the case of a multivalue TLV with separated values per address, but in a single TLV)

Best
Ulrich

 

>From that point of view, I want to understand better your
statements:


On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote:
Yes, I'm concerned about overall performance with position independent TLVs. Specifically, I worry about added complexity to handle position dependence.

How is "performance" in the first sentence related to "complexity" in
the second sentence?  Usually, more complexity enables higher protocol
performance, but at the cost of perhaps reduced parser development
performance (not very likely to affect the performance of the parser).


So I'm advocating for TLVs being as atomic in nature as is possible

I guess that, in this sentence, "atomic" means that one TLV block
does not depend for the definition of its action on:
- its position in the list of TLV blocks, or
- whether or not another specific AddrTLV exists in the Address Block

But these considerations are not related to whether or not the addresses
in the AddrBlk are provided in any positionally dependent fashion.

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------010107040706040209050107-- From abdussalambaryun@gmail.com Tue Jan 22 12:54:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E721F8555 for ; Tue, 22 Jan 2013 12:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyjZ2pwbulq3 for ; Tue, 22 Jan 2013 12:54:49 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B76D021F854E for ; Tue, 22 Jan 2013 12:54:49 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so4198364pbc.31 for ; Tue, 22 Jan 2013 12:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AUUMPSfk01YbB4w+9R1WKsyRo56VZZaH/4OqUoaRPOE=; b=PcavR4GdbRDoV/fMaxZCxogxAWItpC6DjiEnxkZCe9DCdtuTk5BsrLhZivlh5HXZTX 0PeXMdgBq5wOYZkGio307Npe1M76qZAn9IxYhc82Oz2FS7hrEqXlJH9x8zzHCtRgn+7u aQa5AF4iNOpzXB6BdmGNSUxJ5AYur9rlNo2qfPCsYbyezq3ZXbrbdFg9eGk0HLFBgdoW 1sOcr+AiEgDp7w1oRGIW9UPR56XUYdKbxmIsVuXmeYoY+ZWs3aqIUiOQCd4pUCvUZjlb O4wph8DGAtFhlIRnECY0OjFxaMwImY5z6d2tpN2/dUyUZz/68fjHsf4RHKX7cJH3VkiK IH2A== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr43465115pbc.67.1358888089431; Tue, 22 Jan 2013 12:54:49 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 12:54:49 -0800 (PST) In-Reply-To: <50FEFAD9.4020606@computer.org> References: <50EDF2E7.3020105@computer.org> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> Date: Tue, 22 Jan 2013 21:54:49 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:54:50 -0000 I think he ment to say that it was not possible in AODVv2, maybe I misunderstood AB On 1/22/13, Charles E. Perkins wrote: > > Hello Ulrich, > > Thanks for the clarification. I was aware that each address could have > multiple TLV values applied, one each from different TLVs. I was trying > to explain that, for each such TLV, there could be a distinct value applied > per address. I think your explanation is better. > > Regards, > Charlie P. > > > On 1/22/2013 12:09 PM, Ulrich Herberg wrote: >> Hello Charlie, >> >> On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins >> > wrote: >> >> >> Hello Stan, >> >> RFC 5444 AddrTLVs are "positionally dependent" on the order of >> the addresses in the AddrBlk. In other words, for each address, >> there can be a specific TLV that refers to that address and >> no others. >> >> >> >> I am not quite sure that I understand you correctly. But if you are >> saying that only one TLV value can be associated with one particular >> address, this is not true. Multiple TLVs (and their values if they >> have one) can be associated with one address. There is a special case >> if multiple TLVs of the same type but different value are associated >> with the same address, which is mentioned in section 5.4.2. of RFC5444. >> In addition, one TLV value can be associated with multiple addresses >> (using the same value for each address, or in the case of a multivalue >> TLV with separated values per address, but in a single TLV) >> >> Best >> Ulrich >> >> >> >From that point of view, I want to understand better your >> statements: >> >> >> On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: >> >> Yes, I'm concerned about overall performance with position >> independent TLVs. Specifically, I worry about added complexity >> to handle position dependence. >> >> >> How is "performance" in the first sentence related to "complexity" in >> the second sentence? Usually, more complexity enables higher >> protocol >> performance, but at the cost of perhaps reduced parser development >> performance (not very likely to affect the performance of the >> parser). >> >> >> So I'm advocating for TLVs being as atomic in nature as is >> possible >> >> >> I guess that, in this sentence, "atomic" means that one TLV block >> does not depend for the definition of its action on: >> - its position in the list of TLV blocks, or >> - whether or not another specific AddrTLV exists in the Address Block >> >> But these considerations are not related to whether or not the >> addresses >> in the AddrBlk are provided in any positionally dependent fashion. >> >> -- >> Regards, >> Charlie P. >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Tue Jan 22 13:00:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE5B21F8959 for ; Tue, 22 Jan 2013 13:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LjYEWzLzAVw for ; Tue, 22 Jan 2013 13:00:18 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7721F8956 for ; Tue, 22 Jan 2013 13:00:18 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id rp2so4231841pbb.29 for ; Tue, 22 Jan 2013 13:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ksDZy41lgLuuIIm2Rdnd8PiNz9NbSODE+pw2u6Wasys=; b=UyY5zg29948zxat1kFYt9yZLWmmdJHCCGMtjh9JEfbP1Gz4VM/LuM89j/M/Qja9NKv eFawr/1yTAxJZ/dE3GMEMCgWRyFX2xfmyAeDj6GhNXbZ2FxJhuCfZKJnx69OoUXWu0hR uOeWmCoMprLbBbP4XIQI7bhxZOMyA54Mh1IPvioxkkDC4MCLaKWL0YS69eheVDHpZUS9 rrpRPLdLah3QJBBGO4l7JxSXCGjWioW7iXxmwwic0aBpgd07PZFgvXXtWaK/F5hvApIP lZL/WqugruWnWIlxjrcPk/srUvXRStwX8LCuEBaY5x7ZA1hDmXl0foB8tVr8xyEI8NIP 3c5w== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr42748818pbc.70.1358888417822; Tue, 22 Jan 2013 13:00:17 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 13:00:17 -0800 (PST) In-Reply-To: <70C2274C-6CA9-4639-93EC-B31BB09EBE9B@thomasclausen.org> References: <50EDF2E7.3020105@computer.org> <50EFB929.3000901@fkie.fraunhofer.de> <6F1CF924-B19C-4875-B59B-68DE7083323A@thomasclausen.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <70C2274C-6CA9-4639-93EC-B31BB09EBE9B@thomasclausen.org> Date: Tue, 22 Jan 2013 22:00:17 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:00:18 -0000 On 1/22/13, Thomas Heide Clausen wrote: >> I am not quite sure that I understand you correctly. But if you are saying >> that only one TLV value can be associated with one particular address, >> this is not true. Multiple TLVs (and their values if they have one) can be >> associated with one address. There is a special case if multiple TLVs of >> the same type but different value are associated with the same address, >> which is mentioned in section 5.4.2. of RFC5444. >> In addition, one TLV value can be associated with multiple addresses >> (using the same value for each address, or in the case of a multivalue TLV >> with separated values per address, but in a single TLV) >> > > And, none of that is "positionally dependent". yes for TLV values associated with address we don't need position dependent in AODVv2, AB From abdussalambaryun@gmail.com Tue Jan 22 13:03:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F362E21F84DE for ; Tue, 22 Jan 2013 13:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnA8i++CP6v3 for ; Tue, 22 Jan 2013 13:03:40 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9A321F84D8 for ; Tue, 22 Jan 2013 13:03:40 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so3449390dae.7 for ; Tue, 22 Jan 2013 13:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=63ZZBEAJTE3rzhpjUkUH9xC82OoZ7TIbhGU6qZannVM=; b=qoQshz1CEwOVUKyeGD8mRbCZML7akwiYurkDkv7jBNgJIzK99RuB75xUWFLzdB7Cwf S1R85bVbGbwYGF21J0tDLAQMNeggMwBToZqWkrkVLhpCV+32w7F4ICGmkyD2eK1J27E6 cNvzJHPSmQeQ0T1qx/u4tdwGPP0F9/7/mlPi9PgtKZxgi1wN7YY9rSs1V/9qSfJeM5sb yo1c1lm4JSXxV1kLuFXOwzLt4NRfyCxFYdzsSprT8JwlxSsqRcTMHHyLKGfiF9GvSmG2 R4iUMAPXFh6O8GGAw/ZaGlOYOtrhqGVOjqc+h3ztYufYKUxLcUoJSuXbyl10WQ7ANoF5 LwGQ== MIME-Version: 1.0 X-Received: by 10.66.79.202 with SMTP id l10mr59459048pax.36.1358888619805; Tue, 22 Jan 2013 13:03:39 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 13:03:39 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Jan 2013 22:03:39 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Is it better to Request On-Demand and With-Position Info? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:03:41 -0000 Usually in my design of DSRv2 the addresses TLVs in messages are better position dependent, because it is on-demand routing, AB From charliep@computer.org Tue Jan 22 13:09:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9D521F8959 for ; Tue, 22 Jan 2013 13:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JFcbOrNMl4N for ; Tue, 22 Jan 2013 13:09:48 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 638BE21F8735 for ; Tue, 22 Jan 2013 13:09:48 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Txl6K-0002AU-2L; Tue, 22 Jan 2013 16:09:48 -0500 Message-ID: <50FF0013.8080208@computer.org> Date: Tue, 22 Jan 2013 13:09:39 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86761a19333dc7da54b4cf3b678cccfb41350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Is it better to Request On-Demand and With-Position Info? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:09:49 -0000 Hello Abdussalam, If DSRv2 uses source routes in the same way that DSR uses them, then I would imagine that the RFC 5444 AddrBlk would be highly positionally dependent, at least in the most straightforward evolution of DSR. I think it would be weird to design a source route that didn't have positionally dependent addresses in the AddrBlk of the RREP. Of course it could be done -- one simply designs an accompanying AddrTLV that describes the position of each address in the AddrBlk. Voila! Regards, Charlie P. On 1/22/2013 1:03 PM, Abdussalam Baryun wrote: > Usually in my design of DSRv2 the addresses TLVs in messages are > better position dependent, because it is on-demand routing, > > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From teco@inf-net.nl Tue Jan 22 13:11:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA25D21F8824 for ; Tue, 22 Jan 2013 13:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l725Ag1INxK8 for ; Tue, 22 Jan 2013 13:11:22 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47F21F87AC for ; Tue, 22 Jan 2013 13:11:22 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hq12so3792497wib.4 for ; Tue, 22 Jan 2013 13:11:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NMOG7CQOo3bXe0sIfbOcYIqn3/E1QOPvGNbdQAcjntw=; b=HPMwK5Kc6SGO2B6CQBhotfNXDXgvup777sbvl33eMbrFB4BG0WDja5Hwn7qrONrkV0 8Zin+szxdl+VDZFZIz47tNyu9o8QT+OHA4o3ua+Wy2XnageG5RqZCtkclrqg0Uaw0+kd lOha4RIXsz+TnJVzAY2ZHZUMIiXwTkA8YmSjCGvLCnBfej7BSNZrS3Bniw5+BiKbqLBZ twDNUrSdcvCvDXJlV6DANPgs0ikBXih5eOtmLaZ7kspV6a+faSLzVv3SzM3spVsDJK/y UrXFxyPCAvS8mA3W9x7XswRX1S6mG/7rGYRYmiJTYNTMo2gr+Fh9qBlth3aivcRboTYY 5rLg== X-Received: by 10.194.5.74 with SMTP id q10mr35082055wjq.13.1358889081465; Tue, 22 Jan 2013 13:11:21 -0800 (PST) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id hu8sm23406652wib.6.2013.01.22.13.11.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 13:11:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 22 Jan 2013 22:11:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn1EAA9nLgH1sHxs1MIBY4/iM7aJoHsqJTX4LhBWX26EYD/ckU7ILMbZmDDDFhVrW0q0ClN Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:11:26 -0000 Where 5444 would bring a fairly large compression ratio to NHDP and OLSRv2, I wonder if it is helpful for AODV. If not, we can just skip 5444 or put the message in a TLV. I didn't follow the long track from AODV to our current work, e.g. shortening Sequence Number. Were are we, in terms of message sizes, comparing current proposals to 3561? Assume v4 shared /8 and v6 shared /64, random mids, no tail. Teco Op 22 jan. 2013, om 21:18 heeft Henning Rogge het volgende geschreven: > On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins > wrote: >> Hello Henning, >>> Even if it costs us a few bytes (I forgot about one type of TLV >>> compression), I suggest not doing this. >> >> Well, it's 7 bytes versus 12 bytes. > > No, it might be 49 vs. 54 bytes. Maybe the difference will be even > less compared to the airtime the signal will use up. > >>> We are adding information without any type or attribute to a type based >>> format. We are wasting a lot of potential of the format with this. >> >> I don't understand this. Implementations that don't need to save the >> space would certainly have the other alternatives available, right? >> Plus, I don't exactly understand your point about wasting the potential >> of "the format"...? Which format is being wasted? > > The chance of building MANET protocols with a TLV format... you are > throwing away parts of the advantages of a TLV format. > > Henning Rogge > > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Jan 22 13:22:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDA21F8992 for ; Tue, 22 Jan 2013 13:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5jj3Y6F6Vqo for ; Tue, 22 Jan 2013 13:21:55 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 78C3021F8958 for ; Tue, 22 Jan 2013 13:21:54 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxlI1-0002oY-Hh; Tue, 22 Jan 2013 16:21:53 -0500 Message-ID: <50FF02E8.1080006@computer.org> Date: Tue, 22 Jan 2013 13:21:44 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50EDF2E7.3020105@computer.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86361092481b09248959f0b65cc998d5da350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:22:07 -0000 Hello Abdussalam, I didn't think that Ulrich was denying the possibility of having multiple AddrTLV blocks per AddrBlk in AODVv2. In fact, the last version of the AODVv2 document does specify instances of exactly that feature. Regards, Charlie P. On 1/22/2013 12:54 PM, Abdussalam Baryun wrote: > I think he ment to say that it was not possible in AODVv2, > maybe I misunderstood > > AB > > On 1/22/13, Charles E. Perkins wrote: >> Hello Ulrich, >> >> Thanks for the clarification. I was aware that each address could have >> multiple TLV values applied, one each from different TLVs. I was trying >> to explain that, for each such TLV, there could be a distinct value applied >> per address. I think your explanation is better. >> >> Regards, >> Charlie P. >> >> >> On 1/22/2013 12:09 PM, Ulrich Herberg wrote: >>> Hello Charlie, >>> >>> On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins >>> > wrote: >>> >>> >>> Hello Stan, >>> >>> RFC 5444 AddrTLVs are "positionally dependent" on the order of >>> the addresses in the AddrBlk. In other words, for each address, >>> there can be a specific TLV that refers to that address and >>> no others. >>> >>> >>> >>> I am not quite sure that I understand you correctly. But if you are >>> saying that only one TLV value can be associated with one particular >>> address, this is not true. Multiple TLVs (and their values if they >>> have one) can be associated with one address. There is a special case >>> if multiple TLVs of the same type but different value are associated >>> with the same address, which is mentioned in section 5.4.2. of RFC5444. >>> In addition, one TLV value can be associated with multiple addresses >>> (using the same value for each address, or in the case of a multivalue >>> TLV with separated values per address, but in a single TLV) >>> >>> Best >>> Ulrich >>> >>> >>> >From that point of view, I want to understand better your >>> statements: >>> >>> >>> On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: >>> >>> Yes, I'm concerned about overall performance with position >>> independent TLVs. Specifically, I worry about added complexity >>> to handle position dependence. >>> >>> >>> How is "performance" in the first sentence related to "complexity" in >>> the second sentence? Usually, more complexity enables higher >>> protocol >>> performance, but at the cost of perhaps reduced parser development >>> performance (not very likely to affect the performance of the >>> parser). >>> >>> >>> So I'm advocating for TLVs being as atomic in nature as is >>> possible >>> >>> >>> I guess that, in this sentence, "atomic" means that one TLV block >>> does not depend for the definition of its action on: >>> - its position in the list of TLV blocks, or >>> - whether or not another specific AddrTLV exists in the Address Block >>> >>> But these considerations are not related to whether or not the >>> addresses >>> in the AddrBlk are provided in any positionally dependent fashion. >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> -- >> Regards, >> Charlie P. >> >> -- Regards, Charlie P. From charliep@computer.org Tue Jan 22 13:30:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879B221F8955 for ; Tue, 22 Jan 2013 13:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVxw6U4EHGid for ; Tue, 22 Jan 2013 13:30:23 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67321F8942 for ; Tue, 22 Jan 2013 13:30:23 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TxlQE-0004uA-6T; Tue, 22 Jan 2013 16:30:22 -0500 Message-ID: <50FF04E3.1070204@computer.org> Date: Tue, 22 Jan 2013 13:30:11 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teco Boot References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8650aabad3c9aa599fd6a97c43e9b3eb78350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:30:24 -0000 Hello Teco, I think there are many cases where RFC 5444 will be helpful for AODVv2. In particular, IPv6 addresses are likely to afford quite a bit of address compression. Even if there are only two addresses in RREQ, they could easily share a /56 prefix, saving 7 bytes per transmission. Anyway, I think we are mandated to use RFC 5444 and we shouldn't spend too much time on trying to change that mandate. Regards, Charlie P. On 1/22/2013 1:11 PM, Teco Boot wrote: > Where 5444 would bring a fairly large compression ratio to NHDP and > OLSRv2, I wonder if it is helpful for AODV. If not, we can just skip > 5444 or put the message in a TLV. > > I didn't follow the long track from AODV to our current work, e.g. > shortening Sequence Number. Were are we, in terms of message sizes, > comparing current proposals to 3561? Assume v4 shared /8 and v6 shared > /64, random mids, no tail. > > Teco > > Op 22 jan. 2013, om 21:18 heeft Henning Rogge het volgende geschreven: > >> On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins >> wrote: >>> Hello Henning, >>>> Even if it costs us a few bytes (I forgot about one type of TLV >>>> compression), I suggest not doing this. >>> Well, it's 7 bytes versus 12 bytes. >> No, it might be 49 vs. 54 bytes. Maybe the difference will be even >> less compared to the airtime the signal will use up. >> >>>> We are adding information without any type or attribute to a type based >>>> format. We are wasting a lot of potential of the format with this. >>> I don't understand this. Implementations that don't need to save the >>> space would certainly have the other alternatives available, right? >>> Plus, I don't exactly understand your point about wasting the potential >>> of "the format"...? Which format is being wasted? >> The chance of building MANET protocols with a TLV format... you are >> throwing away parts of the advantages of a TLV format. >> >> Henning Rogge >> >> -- >> We began as wanderers, and we are wanderers still. We have lingured >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From ulrich@herberg.name Tue Jan 22 13:33:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7930021F88EE for ; Tue, 22 Jan 2013 13:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZqBWlrhXuow for ; Tue, 22 Jan 2013 13:33:25 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17221F8984 for ; Tue, 22 Jan 2013 13:33:25 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id fa15so4074319vbb.25 for ; Tue, 22 Jan 2013 13:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z5aeOySPne6VKZOZw8nMfGW8k8nWuNOGUS3yEAjtm28=; b=Yrd5B8M9ggPM7TodjBaDFS7Y1J7zqFBhwPSrWF7iKIVSUBV9TUKN7EU8vseMIOfflV ikiYfZkUP29dLIIt6gARhtqYeRRUamfsqVQdMAwPZUfXBqoro10D1c9Yns3xeJ11fgqY 6L0E14gfhmM16qaSTj8NPBRRH3Y/QRheGclwU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=z5aeOySPne6VKZOZw8nMfGW8k8nWuNOGUS3yEAjtm28=; b=pg+hCixINw1VfgneNoI/HCmGyvJQ7z9Dn/2QOx4xxMk3Gp+vx3xxIydLwOamO1OAQb fw7baLeofweR82W0xzEpcUJgrgcBf/nvsGZ4jZqFERQC4wGw9TBrfZzq7V20dKswUT/2 u9SQCvOrhAO0N2agRSjQE7OOSz5TUtCt3+RW7oj58fnueVpKHXZ3ZomAnzgurYY8Tr/Y XlhcWLCFtsDAoi9uXES7l8fkUhaA3NPiChyu31Zi4E236yVd2arGYyzlXqW3Ml6cFafy WITOvh9a2cW0UBrYJVLhftaIyqLwtxVzgIBB5w0kNEXRUbgP9BXRyjlRKRVRmxBmBu38 f09w== MIME-Version: 1.0 X-Received: by 10.52.36.167 with SMTP id r7mr21984311vdj.108.1358890404577; Tue, 22 Jan 2013 13:33:24 -0800 (PST) Received: by 10.220.33.143 with HTTP; Tue, 22 Jan 2013 13:33:23 -0800 (PST) In-Reply-To: <50FF02E8.1080006@computer.org> References: <50EDF2E7.3020105@computer.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> <50FF02E8.1080006@computer.org> Date: Tue, 22 Jan 2013 13:33:23 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf30780ca4da81c004d3e7531d X-Gm-Message-State: ALoCoQmuVQjYnUCDmbDsk6HHd+8I57ExQFan18OqkfA7bFJXF9IHEZUf5wLELhqbTgceh729AhEu Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:33:26 -0000 --20cf30780ca4da81c004d3e7531d Content-Type: text/plain; charset=ISO-8859-1 AB, I was not saying that positional information within address blocks would not be possible, just that I think it is a bad idea. Also, it is possible to have multiple address blocks, but I don't think that a protocol should mandate how to use address blocks (e.g. how many address blocks, in which order, which addresses in which address block etc); this is the responsibility of the RFC5444 generator (for the reasons Henning and others mentioned). Note that each address block is followed by exactly one "address block TLV block", to use the correct terminology, as expressed by RFC5444: ()* Best Ulrich On Tue, Jan 22, 2013 at 1:21 PM, Charles E. Perkins wrote: > > Hello Abdussalam, > > I didn't think that Ulrich was denying the possibility of having multiple > AddrTLV blocks per AddrBlk in AODVv2. In fact, the last version of > the AODVv2 document does specify instances of exactly that feature. > > Regards, > Charlie P. > > > > On 1/22/2013 12:54 PM, Abdussalam Baryun wrote: > >> I think he ment to say that it was not possible in AODVv2, >> maybe I misunderstood >> >> AB >> >> On 1/22/13, Charles E. Perkins wrote: >> >>> Hello Ulrich, >>> >>> Thanks for the clarification. I was aware that each address could have >>> multiple TLV values applied, one each from different TLVs. I was trying >>> to explain that, for each such TLV, there could be a distinct value >>> applied >>> per address. I think your explanation is better. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 1/22/2013 12:09 PM, Ulrich Herberg wrote: >>> >>>> Hello Charlie, >>>> >>>> On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins >>>> **> wrote: >>>> >>>> >>>> Hello Stan, >>>> >>>> RFC 5444 AddrTLVs are "positionally dependent" on the order of >>>> the addresses in the AddrBlk. In other words, for each address, >>>> there can be a specific TLV that refers to that address and >>>> no others. >>>> >>>> >>>> >>>> I am not quite sure that I understand you correctly. But if you are >>>> saying that only one TLV value can be associated with one particular >>>> address, this is not true. Multiple TLVs (and their values if they >>>> have one) can be associated with one address. There is a special case >>>> if multiple TLVs of the same type but different value are associated >>>> with the same address, which is mentioned in section 5.4.2. of RFC5444. >>>> In addition, one TLV value can be associated with multiple addresses >>>> (using the same value for each address, or in the case of a multivalue >>>> TLV with separated values per address, but in a single TLV) >>>> >>>> Best >>>> Ulrich >>>> >>>> >>>> >From that point of view, I want to understand better your >>>> statements: >>>> >>>> >>>> On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: >>>> >>>> Yes, I'm concerned about overall performance with position >>>> independent TLVs. Specifically, I worry about added complexity >>>> to handle position dependence. >>>> >>>> >>>> How is "performance" in the first sentence related to "complexity" >>>> in >>>> the second sentence? Usually, more complexity enables higher >>>> protocol >>>> performance, but at the cost of perhaps reduced parser development >>>> performance (not very likely to affect the performance of the >>>> parser). >>>> >>>> >>>> So I'm advocating for TLVs being as atomic in nature as is >>>> possible >>>> >>>> >>>> I guess that, in this sentence, "atomic" means that one TLV block >>>> does not depend for the definition of its action on: >>>> - its position in the list of TLV blocks, or >>>> - whether or not another specific AddrTLV exists in the Address >>>> Block >>>> >>>> But these considerations are not related to whether or not the >>>> addresses >>>> in the AddrBlk are provided in any positionally dependent fashion. >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> ______________________________**_________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/manet >>>> >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/manet >>>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >>> > > -- > Regards, > Charlie P. > > --20cf30780ca4da81c004d3e7531d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

I was not saying that positional information within address bloc= ks would not be possible, just that I think it is a bad idea. Also, it is p= ossible to have multiple address blocks, but I don't think that a proto= col should mandate how to use address blocks (e.g. how many address blocks,= in which order, which addresses in which address block etc); this is the r= esponsibility of the RFC5444 generator (for the reasons Henning and others = mentioned).
Note that each address block is followed by exactly one "address block= TLV block", to use the correct terminology, as expressed by RFC5444:<= br>(<addr-block><tlv-block>)*

Best
Ulrich

On Tue, Jan 22, 2013 at 1:21 PM, Charles E. Perk= ins <charliep@computer.org> wrote:

Hello Abdussalam,

I didn't think that Ulrich was denying the possibility of having multip= le
AddrTLV blocks per AddrBlk in AODVv2. =A0In fact, the last version of
the AODVv2 document does specify instances of exactly that feature.

Regards,
Charlie P.



On 1/22/2013 12:54 PM, Abdussalam Baryun wrote:
I think he ment to say that it was not possible in AODVv2,
maybe I misunderstood

AB

On 1/22/13, Charles E. Perkins <charliep@computer.org> wrote:
Hello Ulrich,

Thanks for the clarification. =A0I was aware that each address could have multiple TLV values applied, one each from different TLVs. =A0I was trying<= br> to explain that, for each such TLV, there could be a distinct value applied=
per address. =A0I think your explanation is better.

Regards,
Charlie P.


On 1/22/2013 12:09 PM, Ulrich Herberg wrote:
Hello Charlie,

On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins
<charliep@com= puter.org <mailto:charliep@computer.org>> wrote:


=A0 =A0 =A0Hello Stan,

=A0 =A0 =A0RFC 5444 AddrTLVs are "positionally dependent" on the = order of
=A0 =A0 =A0the addresses in the AddrBlk. =A0In other words, for each addres= s,
=A0 =A0 =A0there can be a specific TLV <value> that refers to that ad= dress and
=A0 =A0 =A0no others.



I am not quite sure that I understand you correctly. But if you are
saying that only one TLV value can be associated with one particular
address, this is not true. Multiple TLVs (and their values if they
have one) can be associated with one address. There is a special case
if multiple TLVs of the same type but different value are associated
with the same address, which is mentioned in section 5.4.2. of RFC5444.
In addition, one TLV value can be associated with multiple addresses
(using the same value for each address, or in the case of a multivalue
TLV with separated values per address, but in a single TLV)

Best
Ulrich


=A0 =A0 =A0>From that point of view, I want to understand better your =A0 =A0 =A0statements:


=A0 =A0 =A0On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote:

=A0 =A0 =A0 =A0 =A0Yes, I'm concerned about overall performance with po= sition
=A0 =A0 =A0 =A0 =A0independent TLVs. Specifically, I worry about added comp= lexity
=A0 =A0 =A0 =A0 =A0to handle position dependence.


=A0 =A0 =A0How is "performance" in the first sentence related to = "complexity" in
=A0 =A0 =A0the second sentence? =A0Usually, more complexity enables higher<= br> protocol
=A0 =A0 =A0performance, but at the cost of perhaps reduced parser developme= nt
=A0 =A0 =A0performance (not very likely to affect the performance of the =A0 =A0 =A0parser).


=A0 =A0 =A0 =A0 =A0So I'm advocating for TLVs being as atomic in nature= as is
=A0 =A0 =A0 =A0 =A0possible


=A0 =A0 =A0I guess that, in this sentence, "atomic" means that on= e TLV block
=A0 =A0 =A0does not depend for the definition of its action on:
=A0 =A0 =A0- its position in the list of TLV blocks, or
=A0 =A0 =A0- whether or not another specific AddrTLV exists in the Address = Block

=A0 =A0 =A0But these considerations are not related to whether or not the =A0 =A0 =A0addresses
=A0 =A0 =A0in the AddrBlk are provided in any positionally dependent fashio= n.

=A0 =A0 =A0--
=A0 =A0 =A0Regards,
=A0 =A0 =A0Charlie P.


=A0 =A0 =A0_______________________________________________
=A0 =A0 =A0manet mailing list
=A0 =A0 =A0manet@ietf.o= rg <mailto:manet= @ietf.org>
=A0 =A0 =A0https://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--
Regards,
Charlie P.




--
Regards,
Charlie P.


--20cf30780ca4da81c004d3e7531d-- From teco@inf-net.nl Tue Jan 22 14:09:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48AA21F89CE for ; Tue, 22 Jan 2013 14:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw-9RgukiUi6 for ; Tue, 22 Jan 2013 14:09:59 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id D4F8821F89AE for ; Tue, 22 Jan 2013 14:09:55 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so4680332wgb.1 for ; Tue, 22 Jan 2013 14:09:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=yg6WChnhLcH7vuovQSo1064Y+0JOGvcmb7o9wGWwyfs=; b=d8Dl6Gm7BrA9TwwcU8AXYnkiByRw5TfSORq/z0b3vpagUxz7EexftEYH5ZzRRAdoxh FOkb2BQqhro3GnGRKzB2KZTv1tIWN+0cg25VVgqO4ZCzClsw+J304rOO2rFJVQ6pUq/y KOQxpWR9IIYGV7qyvAGRb1z28pwxbbW0zl6FtNDOsrrdht8lH1J7jllnVP30n62ttTeC aP2YPVUOseAW6nYwPsh+y2x1RzSHI5P+6fAclz0t74nyFQCSmBmB+v4PLXwUem+z/AGt fryuRtsU2+P90jZCPbHJLd0A1z5LKY+yZYGHu3edumkvgza7ZlnV6RJOUgmq79MiYQLU TcPA== X-Received: by 10.194.23.37 with SMTP id j5mr34995330wjf.28.1358892594281; Tue, 22 Jan 2013 14:09:54 -0800 (PST) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id bw9sm23640227wib.5.2013.01.22.14.09.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 14:09:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <50FF04E3.1070204@computer.org> Date: Tue, 22 Jan 2013 23:09:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmgdOos8LPEAcMAkwOKiqTvXDo62uENSzSgpg0Vx9UgXvCYxPYLVCQz0ulLN+Qbe7XhtmmX Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 22:10:00 -0000 Op 22 jan. 2013, om 22:30 heeft Charles E. Perkins het volgende geschreven: > Hello Teco, > > I think there are many cases where RFC 5444 will be helpful for AODVv2. > In particular, IPv6 addresses are likely to afford quite a bit of address > compression. Even if there are only two addresses in RREQ, they could > easily share a /56 prefix, saving 7 bytes per transmission. > > Anyway, I think we are mandated to use RFC 5444 and we shouldn't > spend too much time on trying to change that mandate. I would say: we are guided to use RFC 5444. If it doesn't make sense, ... I understand the multi protocol scenario. So we are at defining the AODVv2 message in 5444. On OrigNode, why not use the element? OK, no compression. But also no TLV needed to point to this address. And msgs without all over the place would break thinks (at least me, using wireshark for debugging and my stats tool). Please help me pointing to an AODVv2 message where an has real benefit. If nothing is on the table, I suggest using just a . Compact and straightforward. Nothing wrong with that, isn't it? Teco > > Regards, > Charlie P. > > > On 1/22/2013 1:11 PM, Teco Boot wrote: >> Where 5444 would bring a fairly large compression ratio to NHDP and >> OLSRv2, I wonder if it is helpful for AODV. If not, we can just skip >> 5444 or put the message in a TLV. >> >> I didn't follow the long track from AODV to our current work, e.g. >> shortening Sequence Number. Were are we, in terms of message sizes, >> comparing current proposals to 3561? Assume v4 shared /8 and v6 shared >> /64, random mids, no tail. >> >> Teco >> Op 22 jan. 2013, om 21:18 heeft Henning Rogge het volgende geschreven: >> >>> On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins >>> wrote: >>>> Hello Henning, >>>>> Even if it costs us a few bytes (I forgot about one type of TLV >>>>> compression), I suggest not doing this. >>>> Well, it's 7 bytes versus 12 bytes. >>> No, it might be 49 vs. 54 bytes. Maybe the difference will be even >>> less compared to the airtime the signal will use up. >>> >>>>> We are adding information without any type or attribute to a type based >>>>> format. We are wasting a lot of potential of the format with this. >>>> I don't understand this. Implementations that don't need to save the >>>> space would certainly have the other alternatives available, right? >>>> Plus, I don't exactly understand your point about wasting the potential >>>> of "the format"...? Which format is being wasted? >>> The chance of building MANET protocols with a TLV format... you are >>> throwing away parts of the advantages of a TLV format. >>> >>> Henning Rogge >>> >>> -- >>> We began as wanderers, and we are wanderers still. We have lingured >>> long enough on the shores of the cosmic ocean. We are ready at last to >>> set sail for the stars - Carl Sagan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > From abdussalambaryun@gmail.com Tue Jan 22 14:14:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42B21F84D3 for ; Tue, 22 Jan 2013 14:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+a6XmpfidZh for ; Tue, 22 Jan 2013 14:14:24 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3265121F84C9 for ; Tue, 22 Jan 2013 14:14:24 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id v40so3458424dad.36 for ; Tue, 22 Jan 2013 14:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JJQEdvkqJCwVtFhZZmIm0KORpc1JgnoPmX2ugQmZ7z8=; b=Osw5AA48oeI+T/ZXrKWo0OPatgtunxztd0h34Z0lXxi3/016TMAhHeer3+XG4hf/oU QF9a+YEez/gA3u3N78IcKv3Jio5inRHEZITPDIkfDJw856DKus68ot/0v02H/vHqkZ8I 7oJsXEuMJJfU2fxouriVyoffILCBmMc0De7AxUCsOAO9KrbImzOahElpXhxQLaBpBGeC k/KOjOzhJao1S4PWI7mraBqySlH5E1cAb4wBEyP4k/V9tmDi5pIMIHPzAUnlOtOlyQNi tfoVVPHaGjEkBX1o8/S00W2RGRwcHwqcRAVPLrZ0B2HXd3BfHzYjh9G8jAIcKjpIfg+S FzKA== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr43357520pbb.43.1358892863950; Tue, 22 Jan 2013 14:14:23 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 14:14:23 -0800 (PST) In-Reply-To: <50FF0013.8080208@computer.org> References: <50FF0013.8080208@computer.org> Date: Tue, 22 Jan 2013 23:14:23 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Is it better to Request On-Demand and With-Position Info? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 22:14:24 -0000 Hi Charlie, I agree with you, and as you mentioned the RFC5444 addrBlk is the way I prefer, AB On 1/22/13, Charles E. Perkins wrote: > > Hello Abdussalam, > > If DSRv2 uses source routes in the same way that DSR uses them, > then I would imagine that the RFC 5444 AddrBlk would be highly > positionally dependent, at least in the most straightforward > evolution of DSR. > > I think it would be weird to design a source route that didn't have > positionally dependent addresses in the AddrBlk of the RREP. > Of course it could be done -- one simply designs an accompanying > AddrTLV that describes the position of each address in the AddrBlk. > Voila! > > Regards, > Charlie P. > > > On 1/22/2013 1:03 PM, Abdussalam Baryun wrote: >> Usually in my design of DSRv2 the addresses TLVs in messages are >> better position dependent, because it is on-demand routing, >> >> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Tue Jan 22 15:04:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2E21F8920 for ; Tue, 22 Jan 2013 15:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWaPowm8vfIl for ; Tue, 22 Jan 2013 15:04:51 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2E21F8746 for ; Tue, 22 Jan 2013 15:04:46 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so3444364dak.5 for ; Tue, 22 Jan 2013 15:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dyKIy8YGT4ntOKPZ0AzrxRcfyPjP2w9l7yZUQUtmchc=; b=k4Syxk+AwfbY9UsrQ4olAKRrBrNx5ThPIbb4Srorx+LVn85OFhJQigiSLGbkfFT1w6 ETw9v9HqtrEo+GcXnmkaDNB85pK9fkimF0YmQg5XeYdp7WLqN5tuCfi1FiB//90k1/H+ wQ+nrR307QrfHqeC7DmGXbgo4uvnbd0n0QXfEDEhxWNiCOee1xfONnmyJ0GnuXQV78Ln +nGaZdUAGNEz+rHdwEQLy4WizL4HoNRhhg7O3XoPrE/w+Dg0ndPehpFW5MXd70OVGSOT NJx1+ZBikFCaph0U+pEOHmFiLIBQnSXLfgQlHserPgM0EXYgPSYVXl/JBZ2978YBf0pt YKZA== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr43602705pbc.70.1358895886523; Tue, 22 Jan 2013 15:04:46 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 15:04:46 -0800 (PST) In-Reply-To: References: <50EDF2E7.3020105@computer.org> <50F5850E.3060809@computer.org> <50F5B539.5000502@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> <50FF02E8.1080006@computer.org> Date: Wed, 23 Jan 2013 00:04:46 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:05:00 -0000 Hi Ulrich, I think you may see that it is a bad idea but that is the only choice I see that RFC5444 serves reactive. I want to try to fix this problem in future by an update for message format. Why cannot 5444 serves both position and non-position info, not sure why it was designed that way? AB On 1/22/13, Ulrich Herberg wrote: > AB, > > I was not saying that positional information within address blocks would > not be possible, just that I think it is a bad idea. Also, it is possible > to have multiple address blocks, but I don't think that a protocol should > mandate how to use address blocks (e.g. how many address blocks, in which > order, which addresses in which address block etc); this is the > responsibility of the RFC5444 generator (for the reasons Henning and others > mentioned). > Note that each address block is followed by exactly one "address block TLV > block", to use the correct terminology, as expressed by RFC5444: > ()* > > Best > Ulrich > > On Tue, Jan 22, 2013 at 1:21 PM, Charles E. Perkins > wrote: > >> >> Hello Abdussalam, >> >> I didn't think that Ulrich was denying the possibility of having multiple >> AddrTLV blocks per AddrBlk in AODVv2. In fact, the last version of >> the AODVv2 document does specify instances of exactly that feature. >> >> Regards, >> Charlie P. >> >> >> >> On 1/22/2013 12:54 PM, Abdussalam Baryun wrote: >> >>> I think he ment to say that it was not possible in AODVv2, >>> maybe I misunderstood >>> >>> AB >>> >>> On 1/22/13, Charles E. Perkins wrote: >>> >>>> Hello Ulrich, >>>> >>>> Thanks for the clarification. I was aware that each address could have >>>> multiple TLV values applied, one each from different TLVs. I was >>>> trying >>>> to explain that, for each such TLV, there could be a distinct value >>>> applied >>>> per address. I think your explanation is better. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> On 1/22/2013 12:09 PM, Ulrich Herberg wrote: >>>> >>>>> Hello Charlie, >>>>> >>>>> On Tue, Jan 22, 2013 at 11:32 AM, Charles E. Perkins >>>>> **> wrote: >>>>> >>>>> >>>>> Hello Stan, >>>>> >>>>> RFC 5444 AddrTLVs are "positionally dependent" on the order of >>>>> the addresses in the AddrBlk. In other words, for each address, >>>>> there can be a specific TLV that refers to that address >>>>> and >>>>> no others. >>>>> >>>>> >>>>> >>>>> I am not quite sure that I understand you correctly. But if you are >>>>> saying that only one TLV value can be associated with one particular >>>>> address, this is not true. Multiple TLVs (and their values if they >>>>> have one) can be associated with one address. There is a special case >>>>> if multiple TLVs of the same type but different value are associated >>>>> with the same address, which is mentioned in section 5.4.2. of >>>>> RFC5444. >>>>> In addition, one TLV value can be associated with multiple addresses >>>>> (using the same value for each address, or in the case of a multivalue >>>>> TLV with separated values per address, but in a single TLV) >>>>> >>>>> Best >>>>> Ulrich >>>>> >>>>> >>>>> >From that point of view, I want to understand better your >>>>> statements: >>>>> >>>>> >>>>> On 1/22/2013 11:15 AM, Stan Ratliff (sratliff) wrote: >>>>> >>>>> Yes, I'm concerned about overall performance with position >>>>> independent TLVs. Specifically, I worry about added >>>>> complexity >>>>> to handle position dependence. >>>>> >>>>> >>>>> How is "performance" in the first sentence related to >>>>> "complexity" >>>>> in >>>>> the second sentence? Usually, more complexity enables higher >>>>> protocol >>>>> performance, but at the cost of perhaps reduced parser >>>>> development >>>>> performance (not very likely to affect the performance of the >>>>> parser). >>>>> >>>>> >>>>> So I'm advocating for TLVs being as atomic in nature as is >>>>> possible >>>>> >>>>> >>>>> I guess that, in this sentence, "atomic" means that one TLV block >>>>> does not depend for the definition of its action on: >>>>> - its position in the list of TLV blocks, or >>>>> - whether or not another specific AddrTLV exists in the Address >>>>> Block >>>>> >>>>> But these considerations are not related to whether or not the >>>>> addresses >>>>> in the AddrBlk are provided in any positionally dependent >>>>> fashion. >>>>> >>>>> -- >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/**listinfo/manet >>>>> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/**listinfo/manet >>>>> >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> >> >> -- >> Regards, >> Charlie P. >> >> > From abdussalambaryun@gmail.com Tue Jan 22 15:15:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD6F21F8992 for ; Tue, 22 Jan 2013 15:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npkIIaY4MKA5 for ; Tue, 22 Jan 2013 15:15:37 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id C15AB21F880B for ; Tue, 22 Jan 2013 15:15:32 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz10so4347918pad.37 for ; Tue, 22 Jan 2013 15:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=s1IIOhqqchN9bqSz8IJxSwASArT+cfcejzZp+VLBZwQ=; b=tYp4xffHPwrNNWTyckiff+cgCKTuYhSf2a5dSqoXiOOgldVEciVxdAa3jdUNeHEd0W zLbkEnJWyYyPotXNfvfm7ykOVhdE74Mfe+XBqSPhEoxVj5UAx1ce+cRxb5LtDsIAkr+F 06c8f1x8hc67bgANdNScReyj1NBxGdNKMecdkgaETay4AobXerpyiI9IW1zPtrGiFesl QNNe2A9AhPFp1mc6GYlxfEgri/cbmSNxcG+Op57M8alAWddmCEFez8Jx1T5SEFw7RjuY jVQtCD/TbrZmdh7/HljAEl9oQKLdulEk0GDvfTscHPU2ohH5jln5XEs61M3otYD6u7Ci Dcuw== MIME-Version: 1.0 X-Received: by 10.66.76.97 with SMTP id j1mr60769686paw.70.1358896531607; Tue, 22 Jan 2013 15:15:31 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 15:15:31 -0800 (PST) Date: Wed, 23 Jan 2013 00:15:31 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Address Order in RFC5444 messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:15:42 -0000 Hi Ulrich, I have some questions in line; On 1/22/13, Ulrich Herberg wrote: > I was not saying that positional information within address blocks would > not be possible, just that I think it is a bad idea. Also, it is possible > to have multiple address blocks, but I don't think that a protocol should > mandate how to use address blocks (e.g. how many address blocks, in which > order, which addresses in which address block etc); this is the > responsibility of the RFC5444 generator (for the reasons Henning and others > mentioned). - In the rfc5444; Who specifies how to use an address or block? is it protocol or generator? - Who is responsible for the address order if needed? - Why rfc5444 was designed to make non-position and ignores the position format? do you think order format is bad idea? AB From abdussalambaryun@gmail.com Tue Jan 22 15:18:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EE621F8654 for ; Tue, 22 Jan 2013 15:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1og9SMw93i-2 for ; Tue, 22 Jan 2013 15:18:03 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id BD20F21F857E for ; Tue, 22 Jan 2013 15:18:02 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so4353930pad.24 for ; Tue, 22 Jan 2013 15:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BOyKyBc+XLYFHaAbLpalNsnzLY9wXSNVWZ8mgV5o4IM=; b=yyVyYEC91mlzI7jTokFvZaNqTSFA676jBbbUWSAMt71fkf4DzIDpxOnOrsuSbHHiZP B1zB/0tbIQeNVHEw7/+kvbnE7mfwHp06FSLUirTmjPpAmGVHdcBEpA0N/12g86bxkF7W T2tCcDn7rag88WirNLQcy+3Qb+YE3AxqGeOt8k58j2crfruBdBU50PgZ/HSUp67uWlx4 +UuAVKDworeTUnXjrjPr0xdubFcpMoCJpPEzcRPlsNKbuDKkoiyePeqwu7s6rBHZ7Ywg hg6SCwm7DoyajOa0KY2oMHIlXlCbULoT61CxTqXb8c7bThN2PInaiP/waVbEpgGlwYIN w2FQ== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr43714985pbc.140.1358896682472; Tue, 22 Jan 2013 15:18:02 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 15:18:02 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Jan 2013 00:18:02 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Address Order in RFC5444 messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:18:04 -0000 >> I was not saying that positional information within address blocks would >> not be possible, just that I think it is a bad idea. Also, it is possible Why is the information should be within the Addblock, I want the info non-position and the address positioned, I think this is better idea, AB From abdussalambaryun@gmail.com Tue Jan 22 18:17:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4BC21F8202 for ; Tue, 22 Jan 2013 18:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A188b-s0Fe-i for ; Tue, 22 Jan 2013 18:17:30 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7A721F84DE for ; Tue, 22 Jan 2013 18:17:30 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id un15so4368884pbc.36 for ; Tue, 22 Jan 2013 18:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tQ2na5gnmpfGz/Hm8z+GfmaBiG4j7+mNlRzVKukHgGk=; b=xSvcRQEopuTlYMJGlBL91gpDG4Jl5LcIJr4pd3E5If6yKanwMbzpWuvp/wGSl/SHFq mbYlEvz1Qs9kYccoKG+2Y2JgWxNzkN5nmaN2DZrTbr7ab+8OXFI2j03mPg7TQ+MsTP9L XowvWBvM5nt1OwSP8XHAvP+CtgRsWsfDGckv9IpPsVf9BB0scktM4iekt40yEFd22Kv0 Q6Kem+GJeW0lHKdX2+oSpk+mku/yf7wRAsXAxzRvKLKLkgqUsaUkZncdGZaWqd3tmE2+ ChsyKdPpPRQkYtiglxc8vzoygPT/yw4SfATjfBvT8jJ8vnfort60OXwLog3fAThBpTzC fKpA== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr44986483pbb.43.1358907449897; Tue, 22 Jan 2013 18:17:29 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 18:17:29 -0800 (PST) In-Reply-To: <50FF0013.8080208@computer.org> References: <50FF0013.8080208@computer.org> Date: Wed, 23 Jan 2013 03:17:29 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Is it better to Request On-Demand and With-Position Info? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 02:17:31 -0000 Hi Charlie, and Ulrich, There may be another way you can do your 5444 messaging in AODVv2 and I do in DSRv2. I may got a hint from your both messages, It may satisfy all, you leave the addressing independent but with associate TLVs for each address of its order-num and time added by router and/or hop-count-of-message, in this way any router will know where/when that address was located. I am not sure if some one mentioned this but sorry if I missed that on the list because now just got the new idea. So addresses and their TLV in the block are independent, but position info of addresses can be understood by DSRv2 router. So we have mix both position and non-position info ( info meaning of position and the info of address independence). I think that satisfy all, Please advise, I am not expert of 5444, but hope the above is right :) Abdussalam Baryun, University of glamorgan, UK On 1/22/13, Charles E. Perkins wrote: > > Hello Abdussalam, > > If DSRv2 uses source routes in the same way that DSR uses them, > then I would imagine that the RFC 5444 AddrBlk would be highly > positionally dependent, at least in the most straightforward > evolution of DSR. > > I think it would be weird to design a source route that didn't have > positionally dependent addresses in the AddrBlk of the RREP. > Of course it could be done -- one simply designs an accompanying > AddrTLV that describes the position of each address in the AddrBlk. > Voila! > > Regards, > Charlie P. > > > On 1/22/2013 1:03 PM, Abdussalam Baryun wrote: >> Usually in my design of DSRv2 the addresses TLVs in messages are >> better position dependent, because it is on-demand routing, >> >> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From ulrich@herberg.name Tue Jan 22 21:37:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC9321F86C5 for ; Tue, 22 Jan 2013 21:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pniiFz2NodBw for ; Tue, 22 Jan 2013 21:37:53 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id BBAA821F86C3 for ; Tue, 22 Jan 2013 21:37:53 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id fa1so4549682pad.21 for ; Tue, 22 Jan 2013 21:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=g3bSQnv+fThgZysCFCEjNgKJSmQx5zwOxDupLVKDqKI=; b=eihglNrJVHSeApo/pvq1H2ENVbgztfzaD3a/+s+qdafR91SbQTvLPhNkMF46P699Mi Yz4IkH7ut++Fa5Eexx+vs+PJ+dU7AlA0a0k2uAT+hgZdsj5FrlXflmsItWniSUZl/gzB Sy9f2fOUuqLoMFO0XCI/n/DYuYqVO2EbS9qe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=g3bSQnv+fThgZysCFCEjNgKJSmQx5zwOxDupLVKDqKI=; b=LzwE8AxVlt0UfrcZL9baYJiwkPJgnbIr+nAtv94M7xnR3ic9xzHQ7/vxiG3w6rCt6b Xlngpk5DHCMh0ktf1vMqC1LLS1TACm4v2BGxdwJam6Z1sOnm/dgldJRiT9WkE5qjoHPJ nyjL7VYFF8Klx4I9R0d6auSwN3fKFXqfA2iK/dKAZHNiC6kg3mkxSJDvKv5yAXBsLYND aB4AlIZAZPo/Ilkvx8baxgtmiwa1QtbPs+K7hjFVfu7YIAiAsOqgr9knuUqRnwGA4QOb 9M4IN5xQWyB1IaBWpDKVGZgMg8pT27p08hsBjhOs/EjOO8M+EjJpinJrT+HeQDkX6JlJ YV3Q== X-Received: by 10.68.228.2 with SMTP id se2mr285048pbc.93.1358919473537; Tue, 22 Jan 2013 21:37:53 -0800 (PST) Received: from ?IPv6:2601:9:3d00:65:9544:ba51:9671:2fb? ([2601:9:3d00:65:9544:ba51:9671:2fb]) by mx.google.com with ESMTPS id x6sm12855500paw.0.2013.01.22.21.37.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 21:37:52 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1DD5F804-A9CB-45FB-B8C1-5C73AE7261A2@herberg.name> X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Tue, 22 Jan 2013 21:37:51 -0800 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQnWfdsywBLkZYEhWjr+13Qak0F2vOTyLovRST0bkORuHN0MyfrL/Tu42WSogbgAwt883dE/ Cc: "manet@ietf.org" Subject: Re: [manet] Address Order in RFC5444 messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 05:37:54 -0000 Hi AB, On Jan 22, 2013, at 15:15, Abdussalam Baryun wr= ote: > Hi Ulrich, >=20 > I have some questions in line; >=20 > On 1/22/13, Ulrich Herberg wrote: >> I was not saying that positional information within address blocks would >> not be possible, just that I think it is a bad idea. Also, it is possible= >> to have multiple address blocks, but I don't think that a protocol should= >> mandate how to use address blocks (e.g. how many address blocks, in which= >> order, which addresses in which address block etc); this is the >> responsibility of the RFC5444 generator (for the reasons Henning and othe= rs >> mentioned). >=20 > - In the rfc5444; Who specifies how to use an address or block? is it > protocol or generator? Essentially, the protocol should just say "here is an address, add that to t= he message. oh, and associate it what that TLV." The generator then does the= rest. As I mentioned before, this should be written down in a BCP (best cur= rent practice). > - Who is responsible for the address order if needed? I think it should be the RFC5444 generator. As Henning mentioned, intelligen= t compression algorithms like the one he implemented can than be applied fro= m the RFC5444 generator. > - Why rfc5444 was designed to make non-position and ignores the > position format? do you think order format is bad idea? I think this would be a longer (but important) answer. Some of it has alread= y been mentioned in emails from Chris, Henning and I before, but I want to p= rovide some more detailed text soon that explains the rationale. Best regards Ulrich > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Tue Jan 22 22:41:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D330021F86E8 for ; Tue, 22 Jan 2013 22:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XucR97t+YAgo for ; Tue, 22 Jan 2013 22:41:23 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B8CBF21F84B6 for ; Tue, 22 Jan 2013 22:41:22 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Txu1Q-0006y6-4e for manet@ietf.org; Wed, 23 Jan 2013 07:41:20 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Txu1Q-0004Ll-20 for manet@ietf.org; Wed, 23 Jan 2013 07:41:20 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 07:41:19 +0100 Message-ID: <50FF860E.30207@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 07:41:18 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> In-Reply-To: <50FF04E3.1070204@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050403070201040909050909" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16553/Wed Jan 23 00:46:50 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 06:41:23 -0000 --------------ms050403070201040909050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/22/2013 10:30 PM, Charles E. Perkins wrote: > > Hello Teco, > > I think there are many cases where RFC 5444 will be helpful for AODVv2.= > In particular, IPv6 addresses are likely to afford quite a bit of addre= ss > compression. Even if there are only two addresses in RREQ, they could > easily share a /56 prefix, saving 7 bytes per transmission. RFC5444 will allow to safe even more space when a node has multiple=20 local addresses. Media access is often as expensive as the short=20 messages of a MANET itself, so it makes sense to reply with all your=20 local IPs (not the linklocal ones of course) to a request on one of them.= Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050403070201040909050909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMwNjQxMThaMCMGCSqGSIb3DQEJBDEWBBQ0DQj2a5b/VefDYjUAS/n2QCD+MTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEASzt2cnNOQpoSFaH6QO1Fa5HwHO3rhp78G/TS0vg2e+DA BEDU3OFOUnm5XNzxowl/E6nVx6hPO72zxsQtQ6xknQEcXx7+6XTmuyhTgFYB7VT6F0xFK+Vf +DKw9SCL1Nui1Trx/6gJNaRgrf/XUTGP3IRJifBV3S3zqkLKQxvNzpCIZGgL2gIZKVCof36p nG++Webtren41dhPliv+82rsIjSL23kE+YkHr74mYZS1Cl/j77vZ6nUlsh/xzxkMSeQCVfG+ 4tXFd9iaLGHjosoU2t0zbKOL0BtWTHphNc+qlPg9clXEh5PZaXTDwc3sjpl5I/yKnVTD/ffe pU0HbjMNuwAAAAAAAA== --------------ms050403070201040909050909-- From henning.rogge@fkie.fraunhofer.de Tue Jan 22 22:44:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA3321F87B6 for ; Tue, 22 Jan 2013 22:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzv9S74qFS0Y for ; Tue, 22 Jan 2013 22:44:58 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1F321F87AC for ; Tue, 22 Jan 2013 22:44:57 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Txu4u-00073i-Pq for manet@ietf.org; Wed, 23 Jan 2013 07:44:56 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Txu4u-0004Mz-NE for manet@ietf.org; Wed, 23 Jan 2013 07:44:56 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 07:44:56 +0100 Message-ID: <50FF86E7.2020203@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 07:44:55 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50EDF2E7.3020105@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> <50FF02E8.1080006@computer.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040607010906010602080302" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16553/Wed Jan 23 00:46:50 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a22a8819f20226a2167e46b22584aa1b Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 06:44:59 -0000 --------------ms040607010906010602080302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: > Hi Ulrich, > > I think you may see that it is a bad idea but that is the only choice > I see that RFC5444 serves reactive. The specification of LOADng proves that you are wrong. It is NOT the=20 only choice. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040607010906010602080302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMwNjQ0NTVaMCMGCSqGSIb3DQEJBDEWBBQ/gQYhyqJb80oRlD+J0tU7tVj+aTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADh0nGUH/C+Jp3iNYv/GK5Z8cbWGFCImi5soEqrMjY1gy xH7BFeCkTVfpoc3zyF5jPZi22H9c05XhIucc12GX4DO4U3cEfj5frKPwLoFvqjYVsml1wLsp c5mukJnvqnVQHhOEZAwqP22/gNOTsunx8Mt2u1joaX1U95NOr5nLTrrCDULULijc/TAF0xsy b/niA/vn6hI7RYueM4RW0Rc1OOdWxY2VUWwFkT5NcsmPW2QkzsFDlmWSc1Pb+yUVYdDrNvMj BKGTqK3PDr5m+8dgAQHBRSFj2u65yFjfJhgGQZEZ4fh2iogbuOie0cT51IcVzRd4LXi2qSP0 /mxd1Z+sHQAAAAAAAA== --------------ms040607010906010602080302-- From ulrich@herberg.name Tue Jan 22 23:16:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C62921F86C5 for ; Tue, 22 Jan 2013 23:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf6Ywm3nE70a for ; Tue, 22 Jan 2013 23:16:31 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 517D721F8694 for ; Tue, 22 Jan 2013 23:16:30 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id un15so4477806pbc.22 for ; Tue, 22 Jan 2013 23:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=IAKbtQ9k+dXMyr+hgoSoxO1OoZeDwCr3Qp7CEfl3vQU=; b=T+M/ASkJX3HDe4wIBADygUEIGlDLl8aVCXw+/jmbrtGFGjgnR16Rntlf+fGF8zrFNP OVMaiuQiYvDs8Uy6kkDahRVtJTfZzIeIQu8hDabvQZoDbTTGfsk9AI2bgc6Vy8nQ8bLl 4mOJt1ihLtqVWwpg8fgI1VDFuNLFaXE4Cx/oE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=IAKbtQ9k+dXMyr+hgoSoxO1OoZeDwCr3Qp7CEfl3vQU=; b=GjoX/3torCmZ+SuisVYLHxLVm3bNJPHuZvUnJqC4p557EqWWtFM1wtX7n93jSoQX9Y fD2nENsbx/H90EgvWkKH7Fjk1D/3+GuqNOt4uANZOUH7xY+P/vlTCR7ebnB1cz4/7eHf Iju8t5k6jXN3cFQUM8o9QsEvv6bOlrVEPRYsjDZ1Lyoi2Rzo4uH045apV1C7qbh+OGNR uzC0MWIAk+HPAbIi3mheUw/TGovPYC60/B0tOX5NDmPh+HxlBvFv7M6e7IYoFYhvBI0R MmvYXBe+1RY2L+8iMAvOUAfMqj3YHe4GlKJUyvBOBwVQ+MZULhbqAe1BD8SRaXr8xQAa MCsg== X-Received: by 10.68.233.196 with SMTP id ty4mr1064753pbc.23.1358925390396; Tue, 22 Jan 2013 23:16:30 -0800 (PST) Received: from ?IPv6:2601:9:3d00:65:1c2a:3e60:e574:1b7b? ([2601:9:3d00:65:1c2a:3e60:e574:1b7b]) by mx.google.com with ESMTPS id mz10sm12286725pbc.37.2013.01.22.23.16.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 23:16:28 -0800 (PST) References: <50EDF2E7.3020105@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> <50FF02E8.1080006@computer.org> <50FF86E7.2020203@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: <50FF86E7.2020203@fkie.fraunhofer.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <30256DE8-0C86-4AD6-8A5B-9EC717990486@herberg.name> X-Mailer: iPhone Mail (10A551) From: Ulrich Herberg Date: Tue, 22 Jan 2013 23:16:22 -0800 To: Henning Rogge X-Gm-Message-State: ALoCoQnv2IAZiWeE08c1YyFDKZcYf7hTiT1q99gZJQQqLl5I6Z5slcrdEAaMCbLwrQDQ1bT2LZRO Cc: "" Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 07:16:32 -0000 I agree with Henning. Ulrich Sent from my iPhone On Jan 22, 2013, at 10:44 PM, Henning Rogge wrote: > On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: >> Hi Ulrich, >>=20 >> I think you may see that it is a bad idea but that is the only choice >> I see that RFC5444 serves reactive. >=20 > The specification of LOADng proves that you are wrong. It is NOT the only c= hoice. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thomas@thomasclausen.org Tue Jan 22 23:30:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4D821F8884 for ; Tue, 22 Jan 2013 23:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id minNeRDzuFwu for ; Tue, 22 Jan 2013 23:30:34 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D41F721F8804 for ; Tue, 22 Jan 2013 23:30:34 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5DB79A4FD7 for ; Tue, 22 Jan 2013 23:30:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D1BDC2C1013; Tue, 22 Jan 2013 23:30:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from 201-9.eduroam.saclay.inria.fr (nat-invites.saclay.inria.fr [195.83.213.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4A1572C1011; Tue, 22 Jan 2013 23:30:23 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: <50FF860E.30207@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 08:30:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08302184-DF15-4D8A-88B9-999C6643F56F@thomasclausen.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <50FF860E.30207@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 07:30:35 -0000 On Jan 23, 2013, at 07:41 , Henning Rogge = wrote: > On 01/22/2013 10:30 PM, Charles E. Perkins wrote: >>=20 >> Hello Teco, >>=20 >> I think there are many cases where RFC 5444 will be helpful for = AODVv2. >> In particular, IPv6 addresses are likely to afford quite a bit of = address >> compression. Even if there are only two addresses in RREQ, they = could >> easily share a /56 prefix, saving 7 bytes per transmission. >=20 > RFC5444 will allow to safe even more space when a node has multiple = local addresses. Media access is often as expensive as the short = messages of a MANET itself, so it makes sense to reply with all your = local IPs (not the linklocal ones of course) to a request on one of = them. >=20 Henning brings up a good point, which was very much taken into account = when designing RFC5444. It would be a mistake to make restrictive = assumptions (such as "an interface never has more than a single = [more-than-LL-scoped] IPv6 address"), in a protocol design - even though = under such a restrictive assumption, an insignificantly more compact = format might result. In IPv4, aggregation is typically of the form of "shared prefix, = multiple distinct addresses" (and in that case, representing the prefix = only once). In IPv6, an interface may (and often does) have multiple = IPv6 addresses, where the structure of these are "different prefixes, = same InterfaceID" (in that case, representing the interfaceID once, and = listing the prefixes). I.e. 5444 supports efficient representation of both (and, a clever = *generic* 5444 generator will be able to produce such efficient = messages, regardless of protocol). Thomas > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thomas@thomasclausen.org Tue Jan 22 23:35:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8401121F87FD for ; Tue, 22 Jan 2013 23:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5Mj5ngsrsUa for ; Tue, 22 Jan 2013 23:35:16 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A80A521F86E6 for ; Tue, 22 Jan 2013 23:35:15 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5BF98A672C for ; Tue, 22 Jan 2013 23:35:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 47FE02C103D; Tue, 22 Jan 2013 23:35:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from 201-9.eduroam.saclay.inria.fr (nat-invites.saclay.inria.fr [195.83.213.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 664A62C103C; Tue, 22 Jan 2013 23:35:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: Date: Wed, 23 Jan 2013 08:35:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> To: Teco Boot X-Mailer: Apple Mail (2.1499) Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 07:35:16 -0000 On Jan 22, 2013, at 23:09 , Teco Boot wrote: >=20 > Op 22 jan. 2013, om 22:30 heeft Charles E. Perkins het volgende = geschreven: >=20 >> Hello Teco, >>=20 >> I think there are many cases where RFC 5444 will be helpful for = AODVv2. >> In particular, IPv6 addresses are likely to afford quite a bit of = address >> compression. Even if there are only two addresses in RREQ, they = could >> easily share a /56 prefix, saving 7 bytes per transmission. >>=20 >> Anyway, I think we are mandated to use RFC 5444 and we shouldn't >> spend too much time on trying to change that mandate. >=20 > I would say: we are guided to use RFC 5444. If it doesn't make sense, = ... >=20 RFC5498 (std. track) section 1 seems to disagree with you here: "All interoperable protocols running on these well-known IANA = allocations MUST conform to [RFC5444]. [RFC5444] provides a common format that = enables one or more protocols to share the IANA allocations defined in this = document unambiguously." I do think that RFC5498 is right on that point....and the solution is, = therefore, simple if a protocol wishes to NOT use RFC5444: it can go = ahead and request different IANA allocations. It, probably, would not be = a MANET wg protocol, in that case. Best, Thomas > I understand the multi protocol scenario. So we are at defining the > AODVv2 message in 5444. >=20 > On OrigNode, why not use the element? OK, no = compression.=20 > But also no TLV needed to point to this address. And msgs without=20 > all over the place would break thinks (at least me, = using=20 > wireshark for debugging and my stats tool). >=20 > Please help me pointing to an AODVv2 message where an has=20= > real benefit. If nothing is on the table, I suggest using just a=20 > . Compact and straightforward. Nothing wrong with that, = isn't=20 > it? >=20 > Teco >=20 >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >> On 1/22/2013 1:11 PM, Teco Boot wrote: >>> Where 5444 would bring a fairly large compression ratio to NHDP and >>> OLSRv2, I wonder if it is helpful for AODV. If not, we can just skip >>> 5444 or put the message in a TLV. >>>=20 >>> I didn't follow the long track from AODV to our current work, e.g. >>> shortening Sequence Number. Were are we, in terms of message sizes, >>> comparing current proposals to 3561? Assume v4 shared /8 and v6 = shared >>> /64, random mids, no tail. >>>=20 >>> Teco >>> Op 22 jan. 2013, om 21:18 heeft Henning Rogge het volgende = geschreven: >>>=20 >>>> On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins >>>> wrote: >>>>> Hello Henning, >>>>>> Even if it costs us a few bytes (I forgot about one type of TLV >>>>>> compression), I suggest not doing this. >>>>> Well, it's 7 bytes versus 12 bytes. >>>> No, it might be 49 vs. 54 bytes. Maybe the difference will be even >>>> less compared to the airtime the signal will use up. >>>>=20 >>>>>> We are adding information without any type or attribute to a type = based >>>>>> format. We are wasting a lot of potential of the format with = this. >>>>> I don't understand this. Implementations that don't need to save = the >>>>> space would certainly have the other alternatives available, = right? >>>>> Plus, I don't exactly understand your point about wasting the = potential >>>>> of "the format"...? Which format is being wasted? >>>> The chance of building MANET protocols with a TLV format... you are >>>> throwing away parts of the advantages of a TLV format. >>>>=20 >>>> Henning Rogge >>>>=20 >>>> --=20 >>>> We began as wanderers, and we are wanderers still. We have lingured >>>> long enough on the shores of the cosmic ocean. We are ready at last = to >>>> set sail for the stars - Carl Sagan >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >> --=20 >> Regards, >> Charlie P. >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Tue Jan 22 23:57:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECEC21F8877 for ; Tue, 22 Jan 2013 23:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsymd4e3ko3Z for ; Tue, 22 Jan 2013 23:57:01 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDE921F8867 for ; Tue, 22 Jan 2013 23:56:59 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so430626wib.10 for ; Tue, 22 Jan 2013 23:56:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0yoVRI4k9t1+30nasJuN3mQg1wjgQkPjTLvgypfIA2g=; b=dssOO6kjLk7PO9B+BUjLQ8wrB5uYgho0DXNeJJZEH/sM+1R9Porp9LV7zVrFG4h0T6 zcfZaIXJ7QVe5AWhifNY/Qqp+ohY1y20ebVX9xe9+iQvy9/Ec80337ot+WwKUJZErA28 pVN9yfMekNEk/UJ0C6bKFs+WC3iznLQl7q8mt6Vp72TuixAaH7GyZ+tUoUVS7m+nEnxF aB3u6TSgXwTrNlksCgU5/6VkctzdcTmTjef6Q2GjIhWe2qNoghcnS2J6+iS0ypdCqE5E r6GiYXiLva/ICQSrPNM1aWGj0B5q1+gYor8XieOdGMDTbhHNCq6eT0pGrD5hUJspJ06J wcCA== X-Received: by 10.194.20.231 with SMTP id q7mr574571wje.44.1358927818774; Tue, 22 Jan 2013 23:56:58 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id s16sm29996391wii.0.2013.01.22.23.56.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jan 2013 23:56:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> Date: Wed, 23 Jan 2013 08:56:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnmH6vPDhWg7rqNFKvq39KUX3WgiBG9u5lqVDN4dOn4Dl4CUECpXUbSyH43Pih0Qay7jWOd Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 07:57:02 -0000 I don't want to spend many cycles on these religious discussions.=20 But I read this RFC5498 very different. When a protocol does not use=20 [RFC5444], it is not interoperable. When it does, it is. It does in no=20= way mandates something. To emphasize: enable !=3D enforce. So yes, RFC5498 is right on that point. :-)=20 You suggest to throw DLEP out of MANET WG, unless it uses 5444? I = *totally*=20 disagree. Let's keep thinking and make smart decisions. I hate this = black=20 and white discussions, real world is grey. No misunderstanding: I still see advantages using 5444 for reactive. Teco Op 23 jan. 2013, om 08:35 heeft Thomas Heide Clausen het volgende = geschreven: >=20 > On Jan 22, 2013, at 23:09 , Teco Boot wrote: >=20 >>=20 >> Op 22 jan. 2013, om 22:30 heeft Charles E. Perkins het volgende = geschreven: >>=20 >>> Hello Teco, >>>=20 >>> I think there are many cases where RFC 5444 will be helpful for = AODVv2. >>> In particular, IPv6 addresses are likely to afford quite a bit of = address >>> compression. Even if there are only two addresses in RREQ, they = could >>> easily share a /56 prefix, saving 7 bytes per transmission. >>>=20 >>> Anyway, I think we are mandated to use RFC 5444 and we shouldn't >>> spend too much time on trying to change that mandate. >>=20 >> I would say: we are guided to use RFC 5444. If it doesn't make sense, = ... >>=20 >=20 > RFC5498 (std. track) section 1 seems to disagree with you here: >=20 > "All interoperable protocols running on these well-known IANA = allocations MUST conform > to [RFC5444]. [RFC5444] provides a common format that = enables one or > more protocols to share the IANA allocations defined in this = document > unambiguously." >=20 > I do think that RFC5498 is right on that point....and the solution is, = therefore, simple if a protocol wishes to NOT use RFC5444: it can go = ahead and request different IANA allocations. It, probably, would not be = a MANET wg protocol, in that case. >=20 > Best, >=20 > Thomas >=20 >=20 >> I understand the multi protocol scenario. So we are at defining the >> AODVv2 message in 5444. >>=20 >> On OrigNode, why not use the element? OK, no = compression.=20 >> But also no TLV needed to point to this address. And msgs without=20 >> all over the place would break thinks (at least me, = using=20 >> wireshark for debugging and my stats tool). >>=20 >> Please help me pointing to an AODVv2 message where an = has=20 >> real benefit. If nothing is on the table, I suggest using just a=20 >> . Compact and straightforward. Nothing wrong with that, = isn't=20 >> it? >>=20 >> Teco >>=20 >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> On 1/22/2013 1:11 PM, Teco Boot wrote: >>>> Where 5444 would bring a fairly large compression ratio to NHDP and >>>> OLSRv2, I wonder if it is helpful for AODV. If not, we can just = skip >>>> 5444 or put the message in a TLV. >>>>=20 >>>> I didn't follow the long track from AODV to our current work, e.g. >>>> shortening Sequence Number. Were are we, in terms of message sizes, >>>> comparing current proposals to 3561? Assume v4 shared /8 and v6 = shared >>>> /64, random mids, no tail. >>>>=20 >>>> Teco >>>> Op 22 jan. 2013, om 21:18 heeft Henning Rogge het volgende = geschreven: >>>>=20 >>>>> On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins >>>>> wrote: >>>>>> Hello Henning, >>>>>>> Even if it costs us a few bytes (I forgot about one type of TLV >>>>>>> compression), I suggest not doing this. >>>>>> Well, it's 7 bytes versus 12 bytes. >>>>> No, it might be 49 vs. 54 bytes. Maybe the difference will be even >>>>> less compared to the airtime the signal will use up. >>>>>=20 >>>>>>> We are adding information without any type or attribute to a = type based >>>>>>> format. We are wasting a lot of potential of the format with = this. >>>>>> I don't understand this. Implementations that don't need to save = the >>>>>> space would certainly have the other alternatives available, = right? >>>>>> Plus, I don't exactly understand your point about wasting the = potential >>>>>> of "the format"...? Which format is being wasted? >>>>> The chance of building MANET protocols with a TLV format... you = are >>>>> throwing away parts of the advantages of a TLV format. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> --=20 >>>>> We began as wanderers, and we are wanderers still. We have = lingured >>>>> long enough on the shores of the cosmic ocean. We are ready at = last to >>>>> set sail for the stars - Carl Sagan >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Regards, >>> Charlie P. >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Wed Jan 23 00:08:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3F821F8621 for ; Wed, 23 Jan 2013 00:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1eP2R0Xlhag for ; Wed, 23 Jan 2013 00:08:05 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4241721F8654 for ; Wed, 23 Jan 2013 00:08:04 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so3670099dae.35 for ; Wed, 23 Jan 2013 00:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mc4f85dED7u12jFv/Atsq5aeiiStRmnvqXbOrhqFWk0=; b=T0PK1GrnfaQ97Ru0LxD59KxY/xxxq4P09uyIOhl/k15aUQjJoOjIDsOPNZj4czOa9c Ijv7QF+T20nPSBRlZwjiLWJzyuL21q+ohExlvHsyFYejEn0FMpEwRblI8LLjMu/Sl5d+ rbUVxYC4HJoCTPYDtmdky3nwYnW0cVgweE2jk2DE3x2wbFsMCU8ALlFHg8TqSGd+q0IG 8J6vkPvndZ3lTB0cHNYhJRAU8wFsIgTjxS4aOY7gfJDpeszqR+rD6+7KGQ70CnqYIbP3 ihJLvVV6BRv1u6xUTHWBD9bqkzBqq0R1WPSwdFXz5wP12gTg0HzZLluxOBEh9pbDgVvq Xe7g== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr1311040pbb.43.1358928482810; Wed, 23 Jan 2013 00:08:02 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:08:02 -0800 (PST) Date: Wed, 23 Jan 2013 09:08:02 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: [manet] Multi Org and Targ in RteMsg (was Re: Notifications from the IETF tools Issue Tracker) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:08:06 -0000 Hi Henning, LOADng uses 5444 but does not have multiple originators only targets, I may misunderstood if so please correct me. However, we may use similar format of LOADng in AODVv2, but we just need to go through the AODVv2 function advantages. In AODVv2 there is possibility to have multiple Org, and Targ addresses within the same message do you have another way to do that. I suggested one way in another thread, but may have a long size message, not sure but like to see AODVv2 authors opinion. Hope to know LoADng authors opinion also, AB On 1/23/13, Henning Rogge wrote: > On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: >> Hi Ulrich, >> >> I think you may see that it is a bad idea but that is the only choice >> I see that RFC5444 serves reactive. > > The specification of LOADng proves that you are wrong. It is NOT the > only choice. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From abdussalambaryun@gmail.com Wed Jan 23 00:09:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A377821F8991 for ; Wed, 23 Jan 2013 00:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C1bXV3XunJ0 for ; Wed, 23 Jan 2013 00:09:23 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2549621F8671 for ; Wed, 23 Jan 2013 00:09:23 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so3681490dal.15 for ; Wed, 23 Jan 2013 00:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0Rwpxme5fEatcRKwxit6WQkuWehNprQjPke9wOQuprI=; b=1IE4SvTO9URkVvv0d6riaYqBng088rUustI0/yBzkaCxPwwpTBDti3pyofxltNnPsp KxZVFVpxMVmzUkxlCN1v0SrT/ZMbI1mkBGK1vkUcdxPOhCrsKpSQ1QOtjY+NB44KGmpr Zq3y8/h77VN5b+ENZPhkdLNXoFmR8T3qUycTeUnTwuR4D7FNDlQar1TY1ah2Muozg2fk DbxLCD9QqNpzzrqG95exqxvrqUOAJDtc6gva/Bg6XVdDyKG84eSEQKm+78OXpyNSDdy6 /9mF5C7m8zxpbO/Oe+vQmd4cQdXhU+IyBbOJ+T9QKGX8cs71yCBQoOjyxMmlOCk3RCsg lbBg== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr1254366pbc.70.1358928562887; Wed, 23 Jan 2013 00:09:22 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:09:22 -0800 (PST) In-Reply-To: <1DD5F804-A9CB-45FB-B8C1-5C73AE7261A2@herberg.name> References: <1DD5F804-A9CB-45FB-B8C1-5C73AE7261A2@herberg.name> Date: Wed, 23 Jan 2013 09:09:22 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Address Order in RFC5444 messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:09:23 -0000 Thanks Ulrich, will wait your text on that last question, AB On 1/23/13, Ulrich Herberg wrote: > Hi AB, > > On Jan 22, 2013, at 15:15, Abdussalam Baryun > wrote: > >> Hi Ulrich, >> >> I have some questions in line; >> >> On 1/22/13, Ulrich Herberg wrote: >>> I was not saying that positional information within address blocks would >>> not be possible, just that I think it is a bad idea. Also, it is >>> possible >>> to have multiple address blocks, but I don't think that a protocol >>> should >>> mandate how to use address blocks (e.g. how many address blocks, in >>> which >>> order, which addresses in which address block etc); this is the >>> responsibility of the RFC5444 generator (for the reasons Henning and >>> others >>> mentioned). >> >> - In the rfc5444; Who specifies how to use an address or block? is it >> protocol or generator? > > Essentially, the protocol should just say "here is an address, add that to > the message. oh, and associate it what that TLV." The generator then does > the rest. As I mentioned before, this should be written down in a BCP (best > current practice). > > >> - Who is responsible for the address order if needed? > > I think it should be the RFC5444 generator. As Henning mentioned, > intelligent compression algorithms like the one he implemented can than be > applied from the RFC5444 generator. > > >> - Why rfc5444 was designed to make non-position and ignores the >> position format? do you think order format is bad idea? > > I think this would be a longer (but important) answer. Some of it has > already been mentioned in emails from Chris, Henning and I before, but I > want to provide some more detailed text soon that explains the rationale. > > Best regards > Ulrich > > >> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Wed Jan 23 00:29:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9839C21F8B16 for ; Wed, 23 Jan 2013 00:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3XHl1JSQp+b for ; Wed, 23 Jan 2013 00:29:22 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id 98A0021F8673 for ; Wed, 23 Jan 2013 00:29:21 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id e20so3705476dak.28 for ; Wed, 23 Jan 2013 00:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=4noIIsspoDQAj9zyBPHI0Cq/Rz+VEca5ptgYECe02kQ=; b=buZo2TZcRJYyiLW4rak2DlOKFuMsrAO2DZYMglAz0OoP9Zzfg3Y5o4g+REwPE+X3oH m2kOnk0FRQ3TfahDjbOXFpnbgefaidMxnHNFzdELytODfE6ItdP0oIRk0sF5mazHrvvg 8O3s9/8dltAzqRslBZ6pVkwkURBBUox1ybV20U54D4wGnSXTbCJO4PK1H+DV4/Bv2E1N l+D2FpPN/3X5G5HHKVxZt49VC7CCSnDwFx48B/S8r20pDXTA0Nv+lG8Gx0jWFLWQ9jAR f3pmqPxVO+QT0zTi+thdV0V1tze+9T+El1t8W1SipROxUCg1F/Q9mdNrHQCsmDIFzlAc EFbw== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr1379848pbc.70.1358929761361; Wed, 23 Jan 2013 00:29:21 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:29:21 -0800 (PST) In-Reply-To: <50FF86E7.2020203@fkie.fraunhofer.de> References: <50EDF2E7.3020105@computer.org> <50FD7BD3.1050803@computer.org> <50FDAD22.7080706@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF83B8@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF8E08@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFF930C@xmb-aln-x03.cisco.com> <50FEE940.6060402@computer.org> <50FEFAD9.4020606@computer.org> <50FF02E8.1080006@computer.org> <50FF86E7.2020203@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 09:29:21 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Notifications from the IETF tools Issue Tracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:29:22 -0000 please read http://www.ietf.org/mail-archive/web/manet/current/msg14803.html AB On 1/23/13, Henning Rogge wrote: > On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: >> Hi Ulrich, >> >> I think you may see that it is a bad idea but that is the only choice >> I see that RFC5444 serves reactive. > > The specification of LOADng proves that you are wrong. It is NOT the > only choice. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From abdussalambaryun@gmail.com Wed Jan 23 00:32:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7A921F8598 for ; Wed, 23 Jan 2013 00:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW0Oex7mabDp for ; Wed, 23 Jan 2013 00:32:21 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id 670E221F85A0 for ; Wed, 23 Jan 2013 00:32:21 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id v40so3664593dad.8 for ; Wed, 23 Jan 2013 00:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7kpdXgwSuaOCp+/m322+aHZtObjABpvaKxNM54x6VuA=; b=kg9U4f5G6hhxMS5WBKAHTgXnHjgwy/vmT12V1/3DncaEXzNAUjNYc27aXqyiFe611t vXTA5s2oJh5RtbjvsvdLO6ZpN9/ekhDcp99bBQhnsCfyPiQ74CxUk3ptYiT7F8mA7Dem cwCvxCxXySaWQvLSLiphf0YD2BYNY7MIKakpCpxAZ//HnsGBJnW7WToaDdudfjs3dKSr LrWrAwCyQomTGKqGzM9ewH9Hrj6dfY4k8sEGX176eOuCsZpEP3InTRBuUzbECvvzpYq/ MulgdMxjp0DnrDjmoXXSfqueeHtbhQP8+cn17PilEUZWoJXlevaJxfA5+OTghimet/wu DycA== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr1230282pbc.140.1358929941175; Wed, 23 Jan 2013 00:32:21 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:32:21 -0800 (PST) In-Reply-To: <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> Date: Wed, 23 Jan 2013 09:32:21 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:32:22 -0000 The current AODVv2 dymo-25 does confirm to rfc5444, not sure what you mean, but we must confirm to 5444 only if we use port of MANET, AB On 1/23/13, Thomas Heide Clausen wrote: > > On Jan 22, 2013, at 23:09 , Teco Boot wrote: > >> >> Op 22 jan. 2013, om 22:30 heeft Charles E. Perkins het volgende >> geschreven: >> >>> Hello Teco, >>> >>> I think there are many cases where RFC 5444 will be helpful for AODVv2. >>> In particular, IPv6 addresses are likely to afford quite a bit of >>> address >>> compression. Even if there are only two addresses in RREQ, they could >>> easily share a /56 prefix, saving 7 bytes per transmission. >>> >>> Anyway, I think we are mandated to use RFC 5444 and we shouldn't >>> spend too much time on trying to change that mandate. >> >> I would say: we are guided to use RFC 5444. If it doesn't make sense, ... >> > > RFC5498 (std. track) section 1 seems to disagree with you here: > > "All interoperable protocols running on these well-known IANA allocations > MUST conform > to [RFC5444]. [RFC5444] provides a common format that enables one or > more protocols to share the IANA allocations defined in this document > unambiguously." > > I do think that RFC5498 is right on that point....and the solution is, > therefore, simple if a protocol wishes to NOT use RFC5444: it can go ahead > and request different IANA allocations. It, probably, would not be a MANET > wg protocol, in that case. > > Best, > > Thomas > > >> I understand the multi protocol scenario. So we are at defining the >> AODVv2 message in 5444. >> >> On OrigNode, why not use the element? OK, no compression. >> >> But also no TLV needed to point to this address. And msgs without >> all over the place would break thinks (at least me, using >> >> wireshark for debugging and my stats tool). >> >> Please help me pointing to an AODVv2 message where an has >> real benefit. If nothing is on the table, I suggest using just a >> . Compact and straightforward. Nothing wrong with that, isn't >> it? >> >> Teco >> >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 1/22/2013 1:11 PM, Teco Boot wrote: >>>> Where 5444 would bring a fairly large compression ratio to NHDP and >>>> OLSRv2, I wonder if it is helpful for AODV. If not, we can just skip >>>> 5444 or put the message in a TLV. >>>> >>>> I didn't follow the long track from AODV to our current work, e.g. >>>> shortening Sequence Number. Were are we, in terms of message sizes, >>>> comparing current proposals to 3561? Assume v4 shared /8 and v6 shared >>>> /64, random mids, no tail. >>>> >>>> Teco >>>> Op 22 jan. 2013, om 21:18 heeft Henning Rogge het volgende geschreven: >>>> >>>>> On Tue, Jan 22, 2013 at 7:22 PM, Charles E. Perkins >>>>> wrote: >>>>>> Hello Henning, >>>>>>> Even if it costs us a few bytes (I forgot about one type of TLV >>>>>>> compression), I suggest not doing this. >>>>>> Well, it's 7 bytes versus 12 bytes. >>>>> No, it might be 49 vs. 54 bytes. Maybe the difference will be even >>>>> less compared to the airtime the signal will use up. >>>>> >>>>>>> We are adding information without any type or attribute to a type >>>>>>> based >>>>>>> format. We are wasting a lot of potential of the format with this. >>>>>> I don't understand this. Implementations that don't need to save the >>>>>> space would certainly have the other alternatives available, right? >>>>>> Plus, I don't exactly understand your point about wasting the >>>>>> potential >>>>>> of "the format"...? Which format is being wasted? >>>>> The chance of building MANET protocols with a TLV format... you are >>>>> throwing away parts of the advantages of a TLV format. >>>>> >>>>> Henning Rogge >>>>> >>>>> -- >>>>> We began as wanderers, and we are wanderers still. We have lingured >>>>> long enough on the shores of the cosmic ocean. We are ready at last to >>>>> set sail for the stars - Carl Sagan >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Wed Jan 23 00:39:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBBF21F8566 for ; Wed, 23 Jan 2013 00:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWAMRC-skm6H for ; Wed, 23 Jan 2013 00:39:06 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id D631C21F855C for ; Wed, 23 Jan 2013 00:39:06 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so3698602dae.21 for ; Wed, 23 Jan 2013 00:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DuNON1XEZFVXFvoRd45I1mLde9Y3Nyh0vpQCjQqghMo=; b=05r38IR3LkjBhKEHO/4wus2NjDnd1rCOdPsukGbgBMTwvwiFF6Thr2xoQ0kPwuFp2W yo1E9Lh92KSq2gGbrgg00dhYETKe0P8lS+JCTe+45xXYCUKhkeKMg+nuzyCjumX9isNi LWTZtPXBVLl47spP18Vl4xZbfQQAEaftDN92cVxFpOSnQqHqRZSH0+WtO3SUVU9bx/WF LaW2IDUNgPuJpplRdXH7QRzVvKDAvpkTMAYz5HBbixte3oSBr2t5v9xrpIpJrKn/IGRv r4XPixWy9vCG+h0WTlGpe0xggK31bcwsUPSZeNr9cOaOMWjhhpmY9H6WOSQ3udNOQYvK 0Big== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr1577107pbc.20.1358930346702; Wed, 23 Jan 2013 00:39:06 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:39:06 -0800 (PST) In-Reply-To: <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> Date: Wed, 23 Jan 2013 09:39:06 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Thomas Heide Clausen Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:39:07 -0000 On 1/23/13, Teco Boot wrote: > I don't want to spend many cycles on these religious discussions. > > But I read this RFC5498 very different. When a protocol does not use > [RFC5444], it is not interoperable. When it does, it is. It does in no > way mandates something. To emphasize: enable != enforce. > I change in statement; When a protocol does not use [RFC5498], it is not interoperable with RFC5444 protocols. However, When it does, it is. I think RFC5498 does mandates use of 5444. Do you agree, AB From abdussalambaryun@gmail.com Wed Jan 23 00:45:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED5321F8689 for ; Wed, 23 Jan 2013 00:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3p2mgvmOX-l for ; Wed, 23 Jan 2013 00:45:23 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3F821F8682 for ; Wed, 23 Jan 2013 00:45:23 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id hz1so4619459pad.40 for ; Wed, 23 Jan 2013 00:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=KEDUGBAgvxTLt8FsdE7VNxrX97pULCo6ojesWqD2yoA=; b=lSacZE5ZzwNnQOPF6dLmYZ5w0PH6NDHrqKK7/iqrfAKTJm3DF8bptpI6AYRqUX1C7V jYCmMvwOvxqZZVghvOjkicZHfwtgPVAR47EVE8CSnyyLNZLAYRsTENPDqhdJ5aTn5J30 777Ebie/8VMYSrYw8u7YJGq4Y+K2Oc/TyQ5BIntvPeZO3SU1aBVuqnfR+ptLO2RjZ8JK 1TU9wXT/Ju0yjLW0yhN4yhgTZDcVxqSlJehfATzMzmPfksej6bdsZV3rNjqCV0CcM4BQ m6PB1c6fWxfUkKu3ygvtKEiDYH+XldRX8l49l6QOgM8SGEAtLfjFVNJUHUgRm3oR9K15 yvcQ== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr1513641pbc.67.1358930711767; Wed, 23 Jan 2013 00:45:11 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:45:11 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Jan 2013 09:45:11 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Multi Org and Targ in RteMsg (was Re: Notifications from the IETF tools Issue Tracker) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:45:25 -0000 For AODV it is nice performance to protocol to have more than one org-targ path in one 5444 message, and also for DSR as well, however, I want also in DSRv2 to have order in the path addresses within one 5444 message, AB On 1/23/13, Abdussalam Baryun wrote: > Hi Henning, > > LOADng uses 5444 but does not have multiple originators only targets, > I may misunderstood if so please correct me. However, we may use > similar format of LOADng in AODVv2, but we just need to go through the > AODVv2 function advantages. In AODVv2 there is possibility to have > multiple Org, and Targ addresses within the same message do you have > another way to do that. > > I suggested one way in another thread, but may have a long size > message, not sure but like to see AODVv2 authors opinion. Hope to know > LoADng authors opinion also, > > AB > > > On 1/23/13, Henning Rogge wrote: >> On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: >>> Hi Ulrich, >>> >>> I think you may see that it is a bad idea but that is the only choice >>> I see that RFC5444 serves reactive. >> >> The specification of LOADng proves that you are wrong. It is NOT the >> only choice. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Wed Jan 23 00:46:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB921F86A1 for ; Wed, 23 Jan 2013 00:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiYTgHyCR87s for ; Wed, 23 Jan 2013 00:46:30 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id D557E21F869F for ; Wed, 23 Jan 2013 00:46:29 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dq11so2094446wgb.14 for ; Wed, 23 Jan 2013 00:46:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PwXckzy004WjCwEYcZM50wGkXL6BcK52tbmz1YxvVgw=; b=UdldO6HjiKfZclmlbCzGhU1fqHe+igUpTbv7D/bVXg2ku78nJkcV+a23GYIamtdkbG Qp9Qik13GX1Sd8X/Psjf+otarRLfWQpx4KVpQv0GA6kz2KCGibNF3Evt0EjMzEFktDYz SSfJENfkwrG0ZfbpU7tbQND7hNUonzixT8/UVuM0AiD9SQt+r6U3qL8B5UWglnPd4G23 O2yz+echZ7TLqA7FcBqdIwFGEgwz+YS5eZ0IBewYcVCODBpbKaUUI66WacIU612Ts0mG 1basJGhJahkn4ADF8Vi57PLHSot8PNKYHvOonzRwX6RjLpdbHKEHxX474+yE9Q8MR3YT /feg== X-Received: by 10.180.82.170 with SMTP id j10mr887660wiy.2.1358930788695; Wed, 23 Jan 2013 00:46:28 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id eo10sm28395646wib.9.2013.01.23.00.46.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 00:46:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Wed, 23 Jan 2013 09:46:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnk5PY77uGlauVZPXOsM/DgVmRU2/9Vx2nf0jFhfGvWE94RAYtiWnhp9Hqm7ZWlyj54rgDg Cc: manet , Thomas Heide Clausen Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:46:30 -0000 Op 23 jan. 2013, om 09:39 heeft Abdussalam Baryun het volgende geschreven: > On 1/23/13, Teco Boot wrote: >> I don't want to spend many cycles on these religious discussions. >> >> But I read this RFC5498 very different. When a protocol does not use >> [RFC5444], it is not interoperable. When it does, it is. It does in no >> way mandates something. To emphasize: enable != enforce. >> > I change in statement; > > When a protocol does not use > [RFC5498], it is not interoperable with RFC5444 protocols. However, > When it does, it is. I think RFC5498 does mandates use of 5444. > > Do you agree, If you keep the nuances, I agree. 5498 provides good instruments to build completely incompatible protocols. Ever seen an IP manet protocol interworking with an UDP manet protocol? > > AB From teco@inf-net.nl Wed Jan 23 00:50:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE2F21F85B2 for ; Wed, 23 Jan 2013 00:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgRvKBfJ4ozM for ; Wed, 23 Jan 2013 00:50:35 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id A95BA21F85A0 for ; Wed, 23 Jan 2013 00:50:31 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fg15so5207072wgb.9 for ; Wed, 23 Jan 2013 00:50:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gUyDSvJ+qr9cEfYObvYHd0R5i2x0SN81UWkAdXL4R5A=; b=LXqjLjSisXhdBL/duBcxty9XHJgusF431ZQrhpGxP806F6nfYWNTAaXVrla/YqKtBB jIgOsGaImZxACR8Asx/BtQPKfamIkC6x1pOzqMV7pcqWXT8L79a6g+72jf0g6knpoFYz tRwrDjLm9Kd5qPKAIrZP8bdj01iAM5A5GAsv3WNaEvr/GwEO178Liq2XhPq1b0YCyno8 ES3g4jZilaaiMTUHd4yvvYSFh/b2Ip/dQu6io37Pwt88+QT7jORjZkVMVZGc/BcZPcyK RwL4J+xJ9/1goCyRv4nRTBcX839kznkpz7lndPfAUHfnTntTJJXC9jzX8yQKmecOrWyJ ZTfw== X-Received: by 10.180.85.226 with SMTP id k2mr841015wiz.34.1358931030889; Wed, 23 Jan 2013 00:50:30 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e6sm28419566wiz.1.2013.01.23.00.50.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 00:50:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Wed, 23 Jan 2013 09:50:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37910ED2-DB47-4BA8-B188-522AD8EE2729@inf-net.nl> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnKu5qcHkmx+I/WmJ2HfwRYZBDuzZeJzSAWl87CaK3cjpeXKNHbaPAYkaJ0nO6787R+ANQU Cc: manet@ietf.org Subject: Re: [manet] Multi Org and Targ in RteMsg (was Re: Notifications from the IETF tools Issue Tracker) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:50:37 -0000 Op 23 jan. 2013, om 09:45 heeft Abdussalam Baryun het volgende = geschreven: > For AODV it is nice performance to protocol to have more than one > org-targ path in one 5444 message, and also for DSR as well, however, > I want also in DSRv2 to have order in the path addresses within one > 5444 message, As clearly spelled out now, this needs a creative implementation of = 5444. Could be new type of AddrBlk, or some ordering TLV. Or whatever. Why not posting an early draft, instead of repeating yourself here? Teco >=20 > AB >=20 > On 1/23/13, Abdussalam Baryun wrote: >> Hi Henning, >>=20 >> LOADng uses 5444 but does not have multiple originators only targets, >> I may misunderstood if so please correct me. However, we may use >> similar format of LOADng in AODVv2, but we just need to go through = the >> AODVv2 function advantages. In AODVv2 there is possibility to have >> multiple Org, and Targ addresses within the same message do you have >> another way to do that. >>=20 >> I suggested one way in another thread, but may have a long size >> message, not sure but like to see AODVv2 authors opinion. Hope to = know >> LoADng authors opinion also, >>=20 >> AB >>=20 >>=20 >> On 1/23/13, Henning Rogge wrote: >>> On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: >>>> Hi Ulrich, >>>>=20 >>>> I think you may see that it is a bad idea but that is the only = choice >>>> I see that RFC5444 serves reactive. >>>=20 >>> The specification of LOADng proves that you are wrong. It is NOT the >>> only choice. >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Jan 23 00:51:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D813021F85B2 for ; Wed, 23 Jan 2013 00:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31ZcJ39PnIga for ; Wed, 23 Jan 2013 00:51:55 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6A99A21F8555 for ; Wed, 23 Jan 2013 00:51:55 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id jt11so3161532pbb.2 for ; Wed, 23 Jan 2013 00:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JiMW81zeS/8QtGg5fAFsD7pbtruocTLW7LwsxSbCv9M=; b=ChbMdwhcUVzqpF0+dXOhC1AznUekA3Yg0u57sl9+lCQvWKa4HATBnecEkNSuoRvhNE Y4+OmS4/PVD23DajnHEgu8n77/YFI9Fh7QJjrfj0OWiNerwyrAi/tz4N2yCPOAR1KH29 RZHoErhdyxVR2qN68WyFzKNO3YxTbbsDoqgqx2tWTWtFn//aBKRj8kgcdxK/r/7DBS1q kRkvTbUNhHFxTQqStx0GY9zcanD/2rNl9BqKrlmTgqF3JHsI+WD8RTtVEQ+Get+luEeo KR4PB8Pmfw7IC2hKXscVBYpkdFvxvrNbxwvaPSdhFxGG9EEKQsbTGSZFRy8hnpF3gXSG AxyA== MIME-Version: 1.0 X-Received: by 10.66.79.168 with SMTP id k8mr2778067pax.22.1358931115197; Wed, 23 Jan 2013 00:51:55 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:51:55 -0800 (PST) In-Reply-To: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> Date: Wed, 23 Jan 2013 09:51:55 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Thomas Heide Clausen Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:51:56 -0000 Yes your right thanks, AB On 1/23/13, Teco Boot wrote: > > Op 23 jan. 2013, om 09:39 heeft Abdussalam Baryun het volgende geschreven: > >> On 1/23/13, Teco Boot wrote: >>> I don't want to spend many cycles on these religious discussions. >>> >>> But I read this RFC5498 very different. When a protocol does not use >>> [RFC5444], it is not interoperable. When it does, it is. It does in no >>> way mandates something. To emphasize: enable != enforce. >>> >> I change in statement; >> >> When a protocol does not use >> [RFC5498], it is not interoperable with RFC5444 protocols. However, >> When it does, it is. I think RFC5498 does mandates use of 5444. >> >> Do you agree, > If you keep the nuances, I agree. > > 5498 provides good instruments to build completely incompatible protocols. > Ever seen an IP manet protocol interworking with an UDP manet protocol? > > >> >> AB > > From thomas@thomasclausen.org Wed Jan 23 00:55:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D792A21F8652 for ; Wed, 23 Jan 2013 00:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcFKueTbASU9 for ; Wed, 23 Jan 2013 00:55:00 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6D721F863F for ; Wed, 23 Jan 2013 00:55:00 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D13C3A3AC5 for ; Wed, 23 Jan 2013 00:54:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7395C1C07D7; Wed, 23 Jan 2013 00:54:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.130.160.245] (unknown [37.160.23.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5BAF81C0772; Wed, 23 Jan 2013 00:54:57 -0800 (PST) References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <130C27BA-A611-4E9D-BD97-AE7B053D6477@thomasclausen.org> X-Mailer: iPhone Mail (10A551) From: Thomas Heide Clausen Date: Wed, 23 Jan 2013 09:54:46 +0100 To: Teco Boot Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:55:00 -0000 On 23 janv. 2013, at 09:46, Teco Boot wrote: >=20 > Op 23 jan. 2013, om 09:39 heeft Abdussalam Baryun het volgende geschreven:= >=20 >> On 1/23/13, Teco Boot wrote: >>> I don't want to spend many cycles on these religious discussions. >>>=20 >>> But I read this RFC5498 very different. When a protocol does not use >>> [RFC5444], it is not interoperable. When it does, it is. It does in no >>> way mandates something. To emphasize: enable !=3D enforce. >> I change in statement; >>=20 >> When a protocol does not use >> [RFC5498], it is not interoperable with RFC5444 protocols. However, >> When it does, it is. I think RFC5498 does mandates use of 5444. >>=20 >> Do you agree, > If you keep the nuances, I agree. >=20 > 5498 provides good instruments to build completely incompatible protocols.= > Ever seen an IP manet protocol interworking with an UDP manet protocol? >=20 Nitpicking, yes I have: an OLSRv2 router with two interfaces towards differe= nt domains, one of which running over UDP, the other over IP directly. Both h= iving off packets to the same 5444 parser and OLSRv2 code in the same router= , and TC messages crossing seamlessly between the "over UDP" and the "over I= P" domains via said router. The miracle of layers, I know ;) But, I know what you meant, I think ;)=20 >=20 >>=20 >> AB >=20 From abdussalambaryun@gmail.com Wed Jan 23 00:59:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930F421F86FB for ; Wed, 23 Jan 2013 00:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvinHD4+w3Iy for ; Wed, 23 Jan 2013 00:59:13 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA46521F86CD for ; Wed, 23 Jan 2013 00:59:13 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so4539548pbc.31 for ; Wed, 23 Jan 2013 00:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=yGkvOFVqZNx2/mjbUC7538bh7rlySpc5i5NcacQtV4Q=; b=FBKsPDuCaiBe99C4MFcHwpXsCRUuxPQaIaWRPO5c2L4f0CDkHfzPG/5FKjzwnuWuAc FgFtuMjUmwfYZRQ4hy1ZsUikBqd6mFkrI9Zjf4ZC4F1EfHNp9cDo5+CG7+y2YjHe+JVe KifqwYyTayfN9jSKRjMJvlxkYlAeGJCuwXkTn4+NQrh3vn8RxWmqUE1yCwismW9MBGhp /4D/nin04MXWlzrwRQZq+9llapoYNzgcjyaHkFVjHP3WMD78WnHtJhiVM2xlkkWic5XR qrXGImTMcAAcTTG1ZcsgSNufx7X1tuWNFH4ghIKUCvw1YnP3No5OFtpN5Sqsw3ja59E6 fFxg== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr1403402pbc.140.1358931553523; Wed, 23 Jan 2013 00:59:13 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 00:59:13 -0800 (PST) In-Reply-To: <37910ED2-DB47-4BA8-B188-522AD8EE2729@inf-net.nl> References: <37910ED2-DB47-4BA8-B188-522AD8EE2729@inf-net.nl> Date: Wed, 23 Jan 2013 09:59:13 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Multi Org and Targ in RteMsg (was Re: Notifications from the IETF tools Issue Tracker) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:59:14 -0000 Hi Teco, Yes I want to submit the I-D of DSRv2 but it needs to be adjusted, some issues need more ideas. I seem to have some difficulty with 5444, Regarding the ordering TLVs, yes I will add to make router find the path without need for the addresses or AddBlks to be in order. AB On 1/23/13, Teco Boot wrote: > > Op 23 jan. 2013, om 09:45 heeft Abdussalam Baryun het volgende geschreven= : > >> For AODV it is nice performance to protocol to have more than one >> org-targ path in one 5444 message, and also for DSR as well, however, >> I want also in DSRv2 to have order in the path addresses within one >> 5444 message, > > As clearly spelled out now, this needs a creative implementation of 5444. > Could be new type of AddrBlk, or some ordering TLV. Or whatever. > > Why not posting an early draft, instead of repeating yourself here? > > Teco > >> >> AB >> >> On 1/23/13, Abdussalam Baryun wrote: >>> Hi Henning, >>> >>> LOADng uses 5444 but does not have multiple originators only targets, >>> I may misunderstood if so please correct me. However, we may use >>> similar format of LOADng in AODVv2, but we just need to go through the >>> AODVv2 function advantages. In AODVv2 there is possibility to have >>> multiple Org, and Targ addresses within the same message do you have >>> another way to do that. >>> >>> I suggested one way in another thread, but may have a long size >>> message, not sure but like to see AODVv2 authors opinion. Hope to know >>> LoADng authors opinion also, >>> >>> AB >>> >>> >>> On 1/23/13, Henning Rogge wrote: >>>> On 01/23/2013 12:04 AM, Abdussalam Baryun wrote: >>>>> Hi Ulrich, >>>>> >>>>> I think you may see that it is a bad idea but that is the only choice >>>>> I see that RFC5444 serves reactive. >>>> >>>> The specification of LOADng proves that you are wrong. It is NOT the >>>> only choice. >>>> >>>> Henning Rogge >>>> >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>> >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From henning.rogge@fkie.fraunhofer.de Wed Jan 23 01:27:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BE121F8634 for ; Wed, 23 Jan 2013 01:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2-lKO0uB8Um for ; Wed, 23 Jan 2013 01:27:44 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F121F86A8 for ; Wed, 23 Jan 2013 01:27:44 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxwcR-0003Ra-0y for manet@ietf.org; Wed, 23 Jan 2013 10:27:43 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxwcQ-0000R3-Ub for manet@ietf.org; Wed, 23 Jan 2013 10:27:42 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 10:27:42 +0100 Message-ID: <50FFAD0D.2070007@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 10:27:41 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> <130C27BA-A611-4E9D-BD97-AE7B053D6477@thomasclausen.org> In-Reply-To: <130C27BA-A611-4E9D-BD97-AE7B053D6477@thomasclausen.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090008010000010301000503" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16554/Wed Jan 23 06:47:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 09:27:45 -0000 --------------ms090008010000010301000503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/23/2013 09:54 AM, Thomas Heide Clausen wrote: >> 5498 provides good instruments to build completely incompatible >> protocols. Ever seen an IP manet protocol interworking with an UDP >> manet protocol? > > Nitpicking, yes I have: an OLSRv2 router with two interfaces towards > different domains, one of which running over UDP, the other over IP > directly. Both hiving off packets to the same 5444 parser and OLSRv2 > code in the same router, and TC messages crossing seamlessly between > the "over UDP" and the "over IP" domains via said router. I have even played with transmitting RFC5444 messages with 16 bytes addresses over IPv4 UDP. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090008010000010301000503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMwOTI3NDFaMCMGCSqGSIb3DQEJBDEWBBRKzsqdR0Lgdz++C2mIZkAicELPCDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAQgy+55lDcSsOoDe6f4IOOqv3gU/zUE0ShJ+GoDHg2yLD 3ZQJcvaXnywZc1ErZmwqkHkRlJfRBJkS9CpCc9heH2KlmThKsIGjn6T9RyZBkla7Ioc0T4IH 01vToblefTxNsmwCzjSosFkb5MwuPLCAr3keuN1UCa9ZpQyxK9BbCHszAvrOl5qyWVOBbFoG 6LHm/SfNBueSV/lzp6+8uHEdKnVNOdjaPS+mwceM4IJkxZKJYrG72Y5QuztlQk4+cG8FCC6e EF+ub6fMvD3rrAWaRbHx2RJJ3QHZo9nFk+xFnwx4ELNUbNhXa/QUZ8TyD5cSEgapMIwpHts4 4W2H/ODpugAAAAAAAA== --------------ms090008010000010301000503-- From abdussalambaryun@gmail.com Wed Jan 23 01:31:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34DB21F8487 for ; Wed, 23 Jan 2013 01:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDBouqASbHxs for ; Wed, 23 Jan 2013 01:31:58 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 722A021F844E for ; Wed, 23 Jan 2013 01:31:58 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id bi1so4632231pad.8 for ; Wed, 23 Jan 2013 01:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xhBt/6cv/gBBj2r9V8lS4YTrI/JRqlPEzpMvBLYbOPQ=; b=DYsBFECS0xAaJcrr2ooozD9Eqy0Zxqq30bIZ6iLKQj0xvjOLu21v2P22vh0fsT8VB1 k99KCeaC3jxbzrUooXFAe3EDfQnChB9edYiWJCzJsHt2o5OPQb2u0mYhwZHk8rUOxt4n Qo2mRMB6drkcYOgP6xCshdZj48S0ocY1eGp8QTESlfeLxvHglx8UfOSHAmNkedtsWKF2 M98Sv92BipjhuWtj/ulMZOhgQ6OipADzKIdZTYE81vZ8dfWU1LhcCFgVesdBjCE2J/DC sFPMUtKsE4eE0Hw3sXhY9A8lff0t/LeHdVpDkGT2zTEGt3emOqRNkJSMk6/kNbPySQtY 8YIw== MIME-Version: 1.0 X-Received: by 10.66.78.100 with SMTP id a4mr3127420pax.4.1358933518154; Wed, 23 Jan 2013 01:31:58 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 01:31:58 -0800 (PST) In-Reply-To: <130C27BA-A611-4E9D-BD97-AE7B053D6477@thomasclausen.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> <130C27BA-A611-4E9D-BD97-AE7B053D6477@thomasclausen.org> Date: Wed, 23 Jan 2013 10:31:58 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 09:31:59 -0000 On 1/23/13, Thomas Heide Clausen wrote: > Nitpicking, yes I have: an OLSRv2 router with two interfaces towards > different domains, one of which running over UDP, the other over IP > directly. Both hiving off packets to the same 5444 parser and OLSRv2 code in > the same router, and TC messages crossing seamlessly between the "over UDP" > and the "over IP" domains via said router. > > The miracle of layers, I know ;) I think it is miracle of OLSRv2 interfaces to use same packet format but different ports, AB From thomas@thomasclausen.org Wed Jan 23 01:33:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4921F8735 for ; Wed, 23 Jan 2013 01:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tplLIyKBvTC1 for ; Wed, 23 Jan 2013 01:33:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 06A5521F8611 for ; Wed, 23 Jan 2013 01:33:08 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id ACD08557F1A for ; Wed, 23 Jan 2013 01:33:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 866221BC1E93; Wed, 23 Jan 2013 01:33:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from 201-9.eduroam.saclay.inria.fr (nat-invites.saclay.inria.fr [195.83.213.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C988C1BC1E91; Wed, 23 Jan 2013 01:33:06 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: Date: Wed, 23 Jan 2013 10:33:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FAEC1AB-F752-47FF-BAE3-EB2C11E7FC25@thomasclausen.org> References: <50FD9E4A.7010807@computer.org> <50FEA587.1000006@fkie.fraunhofer.de> <50FED8E7.9010106@computer.org> <50FF04E3.1070204@computer.org> <16826A26-F382-49D6-A6F6-E021F1CB6646@thomasclausen.org> <05456FAF-C6D1-44AD-845B-98518915C1F2@inf-net.nl> <130C27BA-A611-4E9D-BD97-AE7B053D6477@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 09:33:08 -0000 On Jan 23, 2013, at 10:31 , Abdussalam Baryun = wrote: > On 1/23/13, Thomas Heide Clausen wrote: >> Nitpicking, yes I have: an OLSRv2 router with two interfaces towards >> different domains, one of which running over UDP, the other over IP >> directly. Both hiving off packets to the same 5444 parser and OLSRv2 = code in >> the same router, and TC messages crossing seamlessly between the = "over UDP" >> and the "over IP" domains via said router. >>=20 >> The miracle of layers, I know ;) >=20 > I think it is miracle of OLSRv2 interfaces to use same packet format > but different ports, I assume you do not mean "different ports" but "port and protocol = number"? But no, that is no miracle - that is very much intentional and by = design. Thomas > AB From nmikou@u-bourgogne.fr Wed Jan 23 01:35:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30EE21F872E; Wed, 23 Jan 2013 01:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl0pkAzVdNOC; Wed, 23 Jan 2013 01:35:51 -0800 (PST) Received: from zproxy02.u-bourgogne.fr (zproxy02.u-bourgogne.fr [193.52.245.254]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5F21F86BE; Wed, 23 Jan 2013 01:35:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy02.u-bourgogne.fr (Postfix) with ESMTP id E38E5E805F; Wed, 23 Jan 2013 10:35:49 +0100 (CET) X-Virus-Scanned: amavisd-new at Received: from zproxy02.u-bourgogne.fr ([127.0.0.1]) by localhost (zproxy02.u-bourgogne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDXZjw6KQ5nc; Wed, 23 Jan 2013 10:35:49 +0100 (CET) Received: from zstore02.rp.u-bourgogne.fr (zstore02.rp.u-bourgogne.fr [192.168.64.82]) by zproxy02.u-bourgogne.fr (Postfix) with ESMTP id 9B61CE806C; Wed, 23 Jan 2013 10:35:49 +0100 (CET) Date: Wed, 23 Jan 2013 10:35:49 +0100 (CET) From: Noufissa Mikou To: manet@ietf.org, manet-bounces@ietf.org Message-ID: <1528927573.6078220.1358933749606.JavaMail.root@zstore02.rp.u-bourgogne.fr> In-Reply-To: <1519920307.6077929.1358933680908.JavaMail.root@zstore02.rp.u-bourgogne.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6078219_543254710.1358933749605" X-Mailer: Zimbra 7.1.4_GA_2568 (ZimbraWebClient - FF3.0 (Win)/7.1.4_GA_2555) Subject: [manet] unsouscribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 09:35:52 -0000 ------=_Part_6078219_543254710.1358933749605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Please, could you unsouscribe me from your mailing list Best regards Noufissa MIKOU noufissa.mikou@u-bourgogne.fr ------=_Part_6078219_543254710.1358933749605 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Please, could you unsouscribe me from your mailing list

Best regards
Noufissa MIKOU

noufissa.mikou@u-bourgogne.fr
------=_Part_6078219_543254710.1358933749605-- From henning.rogge@fkie.fraunhofer.de Wed Jan 23 01:37:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D766921F8499 for ; Wed, 23 Jan 2013 01:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y0wOPOMQnaV for ; Wed, 23 Jan 2013 01:37:45 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C9E9021F8476 for ; Wed, 23 Jan 2013 01:37:44 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Txwm7-0006rc-Ao for manet@ietf.org; Wed, 23 Jan 2013 10:37:43 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Txwm7-0000ln-8C for manet@ietf.org; Wed, 23 Jan 2013 10:37:43 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 10:37:42 +0100 Message-ID: <50FFAF65.3060003@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 10:37:41 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <1528927573.6078220.1358933749606.JavaMail.root@zstore02.rp.u-bourgogne.fr> In-Reply-To: <1528927573.6078220.1358933749606.JavaMail.root@zstore02.rp.u-bourgogne.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090502010808030309090603" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16554/Wed Jan 23 06:47:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b023bd6aafd0ed920562fab22193c372 Subject: Re: [manet] unsouscribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 09:37:45 -0000 --------------ms090502010808030309090603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/23/2013 10:35 AM, Noufissa Mikou wrote: > > Please, could you unsouscribe me from your mailing list > > Best regards > Noufissa MIKOU > > noufissa.mikou@u-bourgogne.fr There is a link to "mailman" at the bottom of each mailing list where=20 you can unsubscribe yourself. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090502010808030309090603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMwOTM3NDFaMCMGCSqGSIb3DQEJBDEWBBT6vugPImmIq/SzIFViDoFwnuXRoTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAujlQu6hljSfhMamBidXknbcQtqddEASvNIfyXUeAMNT/ mx6nGj6EB6iD9NPrVe6JnT5VdbLpwWggDTCvctZbC9Q4Hinhy0polQqXJlj0raSkL3NIGK10 QIJEKxUmeeen0w6MdLnty4Zl0Y0f5KqvO3qUR+GdjkSOwA7pCRR0haiuyUs0oVPDTGFQM0pm Ke9GsIuIwJ4Vfme4Z1UuQQowSTj2BYBV46M7f9bxMskdm8uB8iNxosNqsRT7IiZ+mUIFrtq2 1f/Y0oteTXQ9qrj2CEGhZLNExGMl4h9mvKVp1326Hh3mIV+CcymRKjT1/UKAU4sN9mKDP94B 9QY+ITyeXAAAAAAAAA== --------------ms090502010808030309090603-- From henning.rogge@fkie.fraunhofer.de Wed Jan 23 03:32:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D12921F892B for ; Wed, 23 Jan 2013 03:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRqsNmAzEmEA for ; Wed, 23 Jan 2013 03:32:13 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id DF5E221F8881 for ; Wed, 23 Jan 2013 03:32:12 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TxyYu-0003LU-5V for manet@ietf.org; Wed, 23 Jan 2013 12:32:12 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TxyYu-0003tG-2q for manet@ietf.org; Wed, 23 Jan 2013 12:32:12 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 12:32:11 +0100 Message-ID: <50FFCA3A.5030009@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 12:32:10 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030905000709060702010709" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16554/Wed Jan 23 06:47:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 5471e3af7d52574b30ec22437ed00ccd Subject: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:32:14 -0000 --------------ms030905000709060702010709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable This is an example for a "schema based compression" I am thinking about. = I use NHDP without the address part as an example to describe the idea. This example is not complete, because I still have to work through the=20 details of the address block. Schema Number: 42 ----------------- Header: * Message Type 0 * Optional Fields: mhashoplimit, mhassequencenumber * Address Length: 4 * Hop Limit 1 Mandatory Message TLVs: * TLV type 1 *-- extension type 0 *-- value length 1 Optional Message TLVs: * TLV type 0: *-- extension type 0 *-- value length 1 Compression idea ---------------- Remove everything from RFC5444 message that can be reconstructed from=20 Schema. Use bitfields to describe which optional TLVs are present in=20 TLV-block. The message to be compressed is a normal NHDP message with 4-byte=20 addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with=20 value 0x10 and an INTERVAL_TIME TLV with value 0x01. Compression ----------- The message always starts with the schema number (maybe a two-byte=20 schema number would be better to allow versioning?) # 42 Add compressed msg-size to message. # xx xx If the msg-flags and msg-addr-length field is specified in the schema,=20 skip them. Otherwise add them to the message # (none in this example) Add all optional message header fields that are marked in the flags and=20 are not already defined in the schema. # 12 34 (sequence number value) Add a bitfield with one bit for each Optional Message TLV. Add another=20 bit if TLVs follow that are not present in the Schema. # 80 ( 1st optional message TLV is present, no "other TLVs") Add all mandatory and all selected optional TLVs to the message. Leave=20 out all fields that can be reconstructed from the Schema. # 10 (value of VALIDITY-TIME TLV) # 01 (value of INTERVAL-TIME TLV) If there are other TLVs (not described in the schema), add the number of = bytes needed to describe them and the TLVs itself # (none in this example) Result ------ The complete message (without the address block and its TLVs has been=20 reduced from # 00 yy yy 53 01 12 34 (message header) # 00 08 (tlv block length) # 01 10 01 10 (VALIDITY-TIME 0x10) # 00 10 01 01 (INTERVAL-TIME 0x01) to # 00 xx xx 12 34 80 10 01 Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030905000709060702010709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMxMTMyMTBaMCMGCSqGSIb3DQEJBDEWBBQYWvSMcmJoNvqMAexLvrh8XN0YgjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAKFjpVpWRdC/Lp83uipiNuZvVfUoeR4riUB9gH6yH4X3b xCu/FXrqzEfD4SJl0mF02noPcDCCsqlVdtVk32VzhFnJOku3lroI3uYsZszH2OHA/9VIgRBL IRLLgJqwGC8hoMHgN1ZdANVOG2winc2DiemcVGnj3tCvxDy4crNButrgJhfGYTVRVnkU41k6 6FYqi4NkiZEQVoT/cscQKzJrK4bpFtXui0Z/LQMAKjBZlG/UEebpXVrgMrbY2o699bT+u9qB jW1mT9wQO4+aa6x+j42E6N1AjylmrL82FVozlLI8T+K9OXxJEwUtnVLNY2vWriQneO4FeBhV IhAkZFOArgAAAAAAAA== --------------ms030905000709060702010709-- From trac+manet@trac.tools.ietf.org Wed Jan 23 03:33:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6421F8960 for ; Wed, 23 Jan 2013 03:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyBiXJsOJZRz for ; Wed, 23 Jan 2013 03:33:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D715C21F8780 for ; Wed, 23 Jan 2013 03:33:28 -0800 (PST) Received: from localhost ([127.0.0.1]:33615 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Txya2-0008O1-6G; Wed, 23 Jan 2013 12:33:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Wed, 23 Jan 2013 11:33:22 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/17 Message-ID: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #17: Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:33:29 -0000 #17: Proposed Reactive Protocols' Alternative Message Formats A proposal approach; a)to leave the same address array format as it is in draft-25 but to let all TLVs position independent, b) do as in [1] to maintain the advantage of [2], it may satisfy all opinions, or c) we may use the messages format of draft [3] and make modification if necessary for the AODVv2 function. (I omitted the fourth alternative d) which proposes to not use RFC5444, because we follow the decision made before that this first standard MUST use RFC5444 and RFC5498) In [1] you leave the addressing independent in 5444 messages as done in proactive protocol but with associate TLVs (which explain order) for each address or address type of its info of order-num and/or time added by the router, and/or hop-count-of-message. In this way any router will know where/when that address was located and it relations with others. So addresses and their TLV in the messages are independent, but position info of addresses can be understood router. Please advise your opinion, [1] http://www.ietf.org/mail-archive/web/manet/current/msg14795.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg14803.html [3] http://www.ietf.org/id/draft-clausen-lln-loadng-08.txt Best Regards Abdussalam Baryun, University of Glamorgan, UK -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: dymo | Version: Severity: Active WG Document | Keywords: RFC5444, Address | TLVs ----------------------------------------+---------------------------------- Ticket URL: manet From abdussalambaryun@gmail.com Wed Jan 23 03:41:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9421F8A3E for ; Wed, 23 Jan 2013 03:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjRsXxNTWyvF for ; Wed, 23 Jan 2013 03:41:33 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id A1D0021F8A22 for ; Wed, 23 Jan 2013 03:41:33 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so3332995pab.33 for ; Wed, 23 Jan 2013 03:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=SJnVtPF4om7PIZ5Cyn7iuulFiC3TuaZWfMxTF6JpumU=; b=cnWp5C3RK1p9xSQp/2Tc+zrwZU7QgMRZwa176WMQ49huTZk2xgou/L5p/XDHdqt/jr m+KlXz9PvPfCLvGiA7hQksepqYDczVl8jFBy6vLszC/zqPeputUIoDNVxorscUvCFdKV GWgxbUz8AMzc+3p2BkByZWvkfJtZRXB2fLnVuS+GE1KA9LHls3kRGMQ+wn/wZMEafuEi JrL190wKbsBtQnDbNe8/zPJXf0Wpeprd8eLD1q9rxvTRkiEi6qLHW6qMOmQ6RS6exZTj L3jq2VhE/lqoczvrrE71zv4mr5GOL8+OdZEZCe9Ya8KBWv+2FPcYPCh6nZW0ozWgG+gj i4Ng== MIME-Version: 1.0 X-Received: by 10.69.0.40 with SMTP id av8mr2603705pbd.117.1358941293372; Wed, 23 Jan 2013 03:41:33 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 03:41:33 -0800 (PST) In-Reply-To: <50FFCA3A.5030009@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 12:41:33 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:41:34 -0000 Do you mean new algorithm of compress than one used for OLSRv2, and this was the post you mention that will be posted, AB On 1/23/13, Henning Rogge wrote: > This is an example for a "schema based compression" I am thinking about. > I use NHDP without the address part as an example to describe the idea. > > This example is not complete, because I still have to work through the > details of the address block. > > > Schema Number: 42 > ----------------- > Header: > * Message Type 0 > * Optional Fields: mhashoplimit, mhassequencenumber > * Address Length: 4 > * Hop Limit 1 > > Mandatory Message TLVs: > * TLV type 1 > *-- extension type 0 > *-- value length 1 > > Optional Message TLVs: > * TLV type 0: > *-- extension type 0 > *-- value length 1 > > > > Compression idea > ---------------- > > Remove everything from RFC5444 message that can be reconstructed from > Schema. Use bitfields to describe which optional TLVs are present in > TLV-block. > > The message to be compressed is a normal NHDP message with 4-byte > addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with > value 0x10 and an INTERVAL_TIME TLV with value 0x01. > > > > Compression > ----------- > > The message always starts with the schema number (maybe a two-byte > schema number would be better to allow versioning?) > > # 42 > > Add compressed msg-size to message. > > # xx xx > > If the msg-flags and msg-addr-length field is specified in the schema, > skip them. Otherwise add them to the message > > # (none in this example) > > Add all optional message header fields that are marked in the flags and > are not already defined in the schema. > > # 12 34 (sequence number value) > > Add a bitfield with one bit for each Optional Message TLV. Add another > bit if TLVs follow that are not present in the Schema. > > # 80 ( 1st optional message TLV is present, no "other TLVs") > > Add all mandatory and all selected optional TLVs to the message. Leave > out all fields that can be reconstructed from the Schema. > > # 10 (value of VALIDITY-TIME TLV) > # 01 (value of INTERVAL-TIME TLV) > > If there are other TLVs (not described in the schema), add the number of > bytes needed to describe them and the TLVs itself > > # (none in this example) > > > > Result > ------ > > The complete message (without the address block and its TLVs has been > reduced from > > # 00 yy yy 53 01 12 34 (message header) > # 00 08 (tlv block length) > # 01 10 01 10 (VALIDITY-TIME 0x10) > # 00 10 01 01 (INTERVAL-TIME 0x01) > > to > > # 00 xx xx 12 34 80 10 01 > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From henning.rogge@fkie.fraunhofer.de Wed Jan 23 03:51:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1021F8992 for ; Wed, 23 Jan 2013 03:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuNL8DYX47wz for ; Wed, 23 Jan 2013 03:51:04 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 12C8121F8951 for ; Wed, 23 Jan 2013 03:51:03 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Txyr8-0001YW-8f; Wed, 23 Jan 2013 12:51:02 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Txyr8-0004Qf-5z; Wed, 23 Jan 2013 12:51:02 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 12:51:01 +0100 Message-ID: <50FFCEA1.70307@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 12:50:57 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50FFCA3A.5030009@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050400070304030909000309" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16554/Wed Jan 23 06:47:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b17092e937cef22d8bf42b2c04946c57 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:51:06 -0000 --------------ms050400070304030909000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/23/2013 12:41 PM, Abdussalam Baryun wrote: > Do you mean new algorithm of compress than one used for OLSRv2, No. Its an example for an idea for a schema-based compression for RFC5444. The idea is that you know MORE about the content of your message in a=20 certain deployment than on the generic protocol level. The compression=20 tries to take advantage of this by eliminating lots of redundancy that=20 can be reconstructed from the Schema. > and this was the post you mention that will be posted, Yes. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050400070304030909000309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMxMTUwNTlaMCMGCSqGSIb3DQEJBDEWBBQZdA5awS+8RfagGoE3QiVea3URPzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEANPenqtv9jYKCN5WaRqjG6c+r3G+xH3ipI+3PUVgYQ498 WcT2/OOT6Dwr1Pii2PWHgIKL80BPdc3WxSgWIyrkAEKUBbRQuskNtB+yTO2jDCNR4F8SHupN Mr1H4K4A81LGD6cvA8GjV9pXn2REg/vQD5ZRz5gka20bA1HhwVC6yafXJTG5gD2KBFYhbkdQ df6KvQ9XaAV+1F/EQVRzGheKBzXAQ8SYV+qQpbnuXR0F+sjEfPHOANuUzPxgAQX9/Tox1vYk eMFfPBPMDAO2inMJ6GOgXrHhn+fWHM/QF2cJIhRVzDLqnrFz8lXt2+/4uZwLliLRKTPUK9qQ 0vT0g2YkcAAAAAAAAA== --------------ms050400070304030909000309-- From abdussalambaryun@gmail.com Wed Jan 23 03:57:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EA121F8732 for ; Wed, 23 Jan 2013 03:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxWRWsvo9U0l for ; Wed, 23 Jan 2013 03:57:31 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C32B21F872E for ; Wed, 23 Jan 2013 03:57:30 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so3754488dae.31 for ; Wed, 23 Jan 2013 03:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Kan7+g8OeTc49Fahag3N8jDhguwLohtf9s6BgNJHe5k=; b=uGs1BKxtdRUkYT93fWSJ59LKlhdNOaXTs1AIVzMAzIGJISxt4lcrRMt9NCZxVmgX/V PTZJWTHUOww99c2CVWbR5wn4/uvaB7KgLyr7PrB1XNCJOFAqmZ9DbKRoSRebeKOR8rLh sQ+lPOmmhfCzwRmHxYXB9M2LrmUILyHzNGjOhl5B5kdMOUKOkU70x//8Jl7hBnOTNVWI 4Fm12Jy2ry4TuWjfdZ0Gbh3eWVzsTyrdgjthR8d0cX/jeIkLXD1NIt90RI1H2whImY8/ GSgYjsrQTP6F6dBS2TMRtPPYzc1wrKIGMIp4MTSfgJiK5j1qFE9PNdJJJ6HskdkSumgm EG3w== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr2896158pbb.43.1358942250134; Wed, 23 Jan 2013 03:57:30 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 03:57:30 -0800 (PST) In-Reply-To: <50FFCEA1.70307@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> <50FFCEA1.70307@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 12:57:30 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:57:32 -0000 Ok so this schema can be used for all MANET protocols that use 5444 including OSRv2, am I right, please advise, AB On 1/23/13, Henning Rogge wrote: > On 01/23/2013 12:41 PM, Abdussalam Baryun wrote: >> Do you mean new algorithm of compress than one used for OLSRv2, > > No. > > Its an example for an idea for a schema-based compression for RFC5444. > > The idea is that you know MORE about the content of your message in a > certain deployment than on the generic protocol level. The compression > tries to take advantage of this by eliminating lots of redundancy that > can be reconstructed from the Schema. > > > and this was the post you mention that will be posted, > > Yes. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From henning.rogge@fkie.fraunhofer.de Wed Jan 23 04:03:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9CF21F8A6C for ; Wed, 23 Jan 2013 04:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ig+acseWjSn for ; Wed, 23 Jan 2013 04:03:51 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4D421F8585 for ; Wed, 23 Jan 2013 04:03:50 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Txz3V-00053I-N8; Wed, 23 Jan 2013 13:03:49 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Txz3V-0004oi-KR; Wed, 23 Jan 2013 13:03:49 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Jan 2013 13:03:49 +0100 Message-ID: <50FFD1A4.7040907@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 13:03:48 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50FFCA3A.5030009@fkie.fraunhofer.de> <50FFCEA1.70307@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040500090503060007060202" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16554/Wed Jan 23 06:47:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a22a8819f20226a2167e46b22584aa1b Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 12:03:52 -0000 --------------ms040500090503060007060202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/23/2013 12:57 PM, Abdussalam Baryun wrote: > Ok so this schema can be used for all MANET protocols that use 5444 > including OSRv2, am I right, please advise, Yes, that is the plan. I think it might allow us to focus on clean protocols during the design=20 while being able to get more compact byte encoding on deployment level. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040500090503060007060202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjMxMjAzNDhaMCMGCSqGSIb3DQEJBDEWBBSl/8lZlBHcccGG4yL8Z/9G96RdhzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAkf8d22k6LnpZzAkETgqFT6GUs2d0IvMVbR6+Yd8EL6Yz yDfhBf7lhSF7W9cadU0FzGTFtptxEBlnD1nShx1tkoxWpUoV5FNRezp2tqZOmUFBmTKJOKJB VwCRotqRZNyrSqfKayH4pDtPHDLMM/5fsSgv6N1q7gltWACPZ5QtCBP8oPdVtTt+t83hU15s HSxzx7TS/TNwqtnwwTm7OfuYLI8QFFu8lcTb6SEbtD3iEsdxd+ismAjJudHahcdPrXxeJw4D llhjkdrj0iBtaBIjvIVlmTGc4qBGiECKhXypMLRTJT552viJYhVA2blTq70Z+H7OykKpzBlS Vw1CNYD0xwAAAAAAAA== --------------ms040500090503060007060202-- From jpmacker@gmail.com Wed Jan 23 13:42:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8408A21F8475 for ; Wed, 23 Jan 2013 13:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhtSIDrmZ2To for ; Wed, 23 Jan 2013 13:42:28 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 805B021F8439 for ; Wed, 23 Jan 2013 13:42:28 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so5937583lbb.13 for ; Wed, 23 Jan 2013 13:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xPOnqrnpKRxVdr4US8cCfawCxy3x8sqX1STPASFbGBs=; b=tqb25x53fqqmPnQmeGxnr1HW0kRXeIG8s15aBARxv6b60SvnQmx6QQu/z8raTTiPGG emFtEboLiHQbgETa1c0q8i/b+IUUP6L9zfQ+pu0BS0dg4Ok6cBwtni8IG/Gtx1gOsaoM sAzL2zXTM9cKnG2DJqDEOv9pAHYuXksoyP57tOrLdswCZu0+YxmdZ/lhLwGwRZixkinO bpEOUccznKUhCPTYHYjZdugL9UxK5THG8yKmSPeB8EmhOxJye8QsjZvtkEYxQ988WpXo bjW7vg0A5R+ODmk7F+lScv1I9R4OedFkh/2oSSQ6B/iZkIwbIUJ0lPkVr0sOP5g4CIxQ /CCA== MIME-Version: 1.0 X-Received: by 10.152.114.42 with SMTP id jd10mr2745978lab.31.1358977347448; Wed, 23 Jan 2013 13:42:27 -0800 (PST) Received: by 10.112.132.37 with HTTP; Wed, 23 Jan 2013 13:42:27 -0800 (PST) In-Reply-To: <50FFD1A4.7040907@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> <50FFCEA1.70307@fkie.fraunhofer.de> <50FFD1A4.7040907@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 16:42:27 -0500 Message-ID: From: Joseph Macker To: Henning Rogge Content-Type: multipart/alternative; boundary=f46d040839d10d6e1004d3fb9222 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:42:29 -0000 --f46d040839d10d6e1004d3fb9222 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2013 at 7:03 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 01/23/2013 12:57 PM, Abdussalam Baryun wrote: > >> Ok so this schema can be used for all MANET protocols that use 5444 >> including OSRv2, am I right, please advise, >> > > Yes, that is the plan. > > I think it might allow us to focus on clean protocols during the design > while being able to get more compact byte encoding on deployment level. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d040839d10d6e1004d3fb9222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 23, 2013 at 7:03 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 01/23/2013 12:57 PM, Ab= dussalam Baryun wrote:
Ok so this schema can be used for all MANET protocols that use 5444
including OSRv2, am I right, please advise,

Yes, that is the plan.

I think it might allow us to focus on clean protocols during the design whi= le being able to get more compact byte encoding on deployment level.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--f46d040839d10d6e1004d3fb9222-- From jpmacker@gmail.com Wed Jan 23 13:51:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77521F872E for ; Wed, 23 Jan 2013 13:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bep4pZwVuugO for ; Wed, 23 Jan 2013 13:51:37 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D666621F8790 for ; Wed, 23 Jan 2013 13:51:36 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id eb20so8292518lab.31 for ; Wed, 23 Jan 2013 13:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uuCIXHeZ/wpeR6JuwsrYjgtGI3ftEwyLVlc0B1OO4Ro=; b=bkN1if1x6ZbmfLK0hPs9kdTvQX4HhaCSuhvvFAaUjZ6B4Lp25Cd8FAPrxacRhcb2Wq 1y7c9cPYLbkreOk5v27Xb9umeIbJW2XxZ62BJuc4P6bJZezncYZqHaAMz/wh9nLZc0Kq DpxEKYNoaxVh3mE6VSMr3VtusLM9dBawEMucH9btfMu7gTiRaOp+cdSB+JviMDvp/IjL w9tBmNm79aUzu9nKVs1qkaii/f2TXucuzwa5ByphEFxSemmyT5Y2mwqC2NsAjSbXZcQi u3mzOko2jA0yJuz5dWWL9V5NPg4a8aOCX5EelLUJ0m4VTccODRTcWjRX13oiTdA5+Jmb kDpA== MIME-Version: 1.0 X-Received: by 10.152.104.199 with SMTP id gg7mr2760419lab.14.1358977892785; Wed, 23 Jan 2013 13:51:32 -0800 (PST) Received: by 10.112.132.37 with HTTP; Wed, 23 Jan 2013 13:51:32 -0800 (PST) In-Reply-To: References: <50FFCA3A.5030009@fkie.fraunhofer.de> <50FFCEA1.70307@fkie.fraunhofer.de> <50FFD1A4.7040907@fkie.fraunhofer.de> Date: Wed, 23 Jan 2013 16:51:32 -0500 Message-ID: From: Joseph Macker To: Henning Rogge Content-Type: multipart/alternative; boundary=f46d040890c18e9c9504d3fbb27d Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:51:38 -0000 --f46d040890c18e9c9504d3fbb27d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I, for one, like the idea of considering and discussing how to properly integrate concepts of schema-based compression. On Wed, Jan 23, 2013 at 4:42 PM, Joseph Macker wrote: > > > > On Wed, Jan 23, 2013 at 7:03 AM, Henning Rogge < > henning.rogge@fkie.fraunhofer.de> wrote: > >> On 01/23/2013 12:57 PM, Abdussalam Baryun wrote: >> >>> Ok so this schema can be used for all MANET protocols that use 5444 >>> including OSRv2, am I right, please advise, >>> >> >> Yes, that is the plan. >> >> I think it might allow us to focus on clean protocols during the design >> while being able to get more compact byte encoding on deployment level. >> >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.**fraunhofer.de >> http://www.fkie.fraunhofer.de >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > --f46d040890c18e9c9504d3fbb27d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I, for one, like the idea of considering and discussi= ng how to properly integrate concepts of schema-based compression.


On Wed= , Jan 23, 2013 at 4:42 PM, Joseph Macker <jpmacker@gmail.com> wrote:



On Wed,= Jan 23, 2013 at 7:03 AM, Henning Rogge <henning.rogge@fkie= .fraunhofer.de> wrote:
On 0= 1/23/2013 12:57 PM, Abdussalam Baryun wrote:
Ok so this schema can be used for all MANET protocols that use 5444
including OSRv2, am I right, please advise,

Yes, that is the plan.

I think it might allow us to focus on clean protocols during the design whi= le being able to get more compact byte encoding on deployment level.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_____________________________= __________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--f46d040890c18e9c9504d3fbb27d-- From abdussalambaryun@gmail.com Wed Jan 23 15:58:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3199B21F8713 for ; Wed, 23 Jan 2013 15:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfL4r0exG4Sf for ; Wed, 23 Jan 2013 15:58:46 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5B321F8794 for ; Wed, 23 Jan 2013 15:58:46 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fb1so5124750pad.39 for ; Wed, 23 Jan 2013 15:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n6hnvsny9Paazn4Typo6EnkK5m6AFN3/d1vrcTOKEe8=; b=xx0ZMV2mCNttCSNLiysnSg1qS2/irLZ1XCSHCQq4SSgaiCAbiqnAku26qJbZ0KaR5i Hh/P45OKm3ZaIw6MH2jYFZI3ecHh/nnOmok2huwNQgI9C9nGKlLN7ely3lXuXgg9x8jw d825sUR4RW1fBO9EgDlNeVJcwlLwCK5DQwk04l601IeDndl7SpnyP3yIN2CE6yn9kdda y4yY9k8NBC2vSCDkhXSN5jTaEKI47zp1cpnG4/XVnNPyQVB15xHtI976mZNXNvigAEQJ dvX9wCPXOxmgzDuHoZWj7nxk4OJvgt+3ImXT0Qow7TpKGPRr8Yu1dBhx6kAMPkTOq+X8 uOaQ== MIME-Version: 1.0 X-Received: by 10.66.78.100 with SMTP id a4mr165329pax.4.1358985526105; Wed, 23 Jan 2013 15:58:46 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 15:58:45 -0800 (PST) In-Reply-To: <50FFCA3A.5030009@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 00:58:45 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:58:47 -0000 Hi Henning, I like the idea/plan and hope it can be in I-D in future, this input to contribute to its discussions. If this schema is general for all, I think we may need the schema to be flexible/extendable because may have reasonable limitation (4 opt tlvs only), not sure, but comments/questions inline, On 1/23/13, Henning Rogge wrote: > This is an example for a "schema based compression" I am thinking about. > I use NHDP without the address part as an example to describe the idea. > > This example is not complete, because I still have to work through the > details of the address block. > > > Schema Number: 42 This Schema number will be for All MANET Router Protocols using RFC5444, not only for NHDP, am I correct, All protocol message type in MANET will need to identify its mandatory and optional TLVs to the 42 Schema, (the addresses block as you said will be design in the Schema but later) > ----------------- > Header: > * Message Type 0 > * Optional Fields: mhashoplimit, mhassequencenumber > * Address Length: 4 > * Hop Limit 1 > > Mandatory Message TLVs: > * TLV type 1 > *-- extension type 0 > *-- value length 1 > > Optional Message TLVs: > * TLV type 0: > *-- extension type 0 > *-- value length 1 > > What was the example optional message TLV, not sure, > > Compression idea > ---------------- > > Remove everything from RFC5444 message that can be reconstructed from > Schema. Use bitfields to describe which optional TLVs are present in > TLV-block. > > The message to be compressed is a normal NHDP message with 4-byte > addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with > value 0x10 and an INTERVAL_TIME TLV with value 0x01. > > > > Compression > ----------- > > The message always starts with the schema number (maybe a two-byte > schema number would be better to allow versioning?) > > # 42 > > Add compressed msg-size to message. > > # xx xx > > If the msg-flags and msg-addr-length field is specified in the schema, > skip them. Otherwise add them to the message > > # (none in this example) > > Add all optional message header fields that are marked in the flags and > are not already defined in the schema. > > # 12 34 (sequence number value) > > Add a bitfield with one bit for each Optional Message TLV. Add another > bit if TLVs follow that are not present in the Schema. > > # 80 ( 1st optional message TLV is present, no "other TLVs") So this Schema is limited to 4 known optionals and 4 uknown, do I make sense, and could it itself be extendable, What is the 1st optional message TLV value? I think not given > > Add all mandatory and all selected optional TLVs to the message. Leave > out all fields that can be reconstructed from the Schema. What are the fields that can be reconstructed by Schema 42, was is described here or its pre-configured > > # 10 (value of VALIDITY-TIME TLV) > # 01 (value of INTERVAL-TIME TLV) > > If there are other TLVs (not described in the schema), add the number of > bytes needed to describe them and the TLVs itself > > # (none in this example) > > > > Result > ------ > > The complete message (without the address block and its TLVs has been > reduced from > So I understand you input is for;The Schema part of TLV block compress-describe > # 00 yy yy 53 01 12 34 (message header) > # 00 08 (tlv block length) > # 01 10 01 10 (VALIDITY-TIME 0x10) > # 00 10 01 01 (INTERVAL-TIME 0x01) > > to > > # 00 xx xx 12 34 80 10 01 > So is that the validity time is mandatory and interval time is optional, and both are known to schema 42? As it was mentioned before in AODVv2 discussions the tradeoffs [1] of positional and non-positional. It makes the description of non-positional format message but in a positional format message by schema way this will help for reduce processing which I like that :) Thanks, I think it is good idea, if I misunderstood please advise, [1] http://www.ietf.org/mail-archive/web/manet/current/msg14756.html AB From abdussalambaryun@gmail.com Wed Jan 23 16:04:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5502621F8455 for ; Wed, 23 Jan 2013 16:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prMuDLIhP+Vl for ; Wed, 23 Jan 2013 16:03:59 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id A473E21F844A for ; Wed, 23 Jan 2013 16:03:59 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fb1so5074748pad.25 for ; Wed, 23 Jan 2013 16:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xbRoJZZM7whVrvhyiMXWVjwCrFOZgcALRkMPppo2S2o=; b=QZeVDTcR84cC/2uWUUNNJv+bFU4IxplZVYweO1au0ecPOu1wN4FEFpS+mclKmrH0h6 AFUxYGeTrruvg+ZHYNCWsTTrKIdxM+l9zQJYxf5XIR+M1bD/raZnfjmIiFc806wJ6htd s1wlVJnb+WdSwnJ70um0UPJUV6g68GpdHsbKxJldNwyKbyUT6vgdVOLa+nIQPcqO205H T72T3+XtmwtaXN1S/SRbEje6oDMD8HRMrxu14q9RMETxwjvJkXBNTlfMzv9z7Ypjf+yF +F52TvP+8EoSsATVYvWWB0YOv3GTLhQ8sqaED6a7+P6SF1/Y71TkTiHqZAS6MC4BcQF/ 3GbA== MIME-Version: 1.0 X-Received: by 10.66.79.168 with SMTP id k8mr130688pax.22.1358985839478; Wed, 23 Jan 2013 16:03:59 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 16:03:59 -0800 (PST) In-Reply-To: References: <50FFCA3A.5030009@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 01:03:59 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 00:04:00 -0000 As from AODVv2 discussions the tradeoffs of using RFC5444 messages in positional way or/and non-positional (i.e unspecified) way. Therefore, This Schema you proposed makes the description of non-positional format message but in a positional format message by schema way this will help for reduce processing and lifetime, do you agree please advise, AB On 1/24/13, Abdussalam Baryun wrote: > Hi Henning, > > I like the idea/plan and hope it can be in I-D in future, this input > to contribute to its discussions. If this schema is general for all, I > think we may need the schema to be flexible/extendable because may > have reasonable limitation (4 opt tlvs only), not sure, but > comments/questions inline, > > On 1/23/13, Henning Rogge wrote: >> This is an example for a "schema based compression" I am thinking about. >> I use NHDP without the address part as an example to describe the idea. >> >> This example is not complete, because I still have to work through the >> details of the address block. >> >> >> Schema Number: 42 > > This Schema number will be for All MANET Router Protocols using > RFC5444, not only for NHDP, am I correct, > > All protocol message type in MANET will need to identify its mandatory > and optional TLVs to the 42 Schema, (the addresses block as you said > will be design in the Schema but later) > >> ----------------- >> Header: >> * Message Type 0 >> * Optional Fields: mhashoplimit, mhassequencenumber >> * Address Length: 4 >> * Hop Limit 1 >> >> Mandatory Message TLVs: >> * TLV type 1 >> *-- extension type 0 >> *-- value length 1 >> >> Optional Message TLVs: >> * TLV type 0: >> *-- extension type 0 >> *-- value length 1 >> >> > > What was the example optional message TLV, not sure, > >> >> Compression idea >> ---------------- >> >> Remove everything from RFC5444 message that can be reconstructed from >> Schema. Use bitfields to describe which optional TLVs are present in >> TLV-block. >> >> The message to be compressed is a normal NHDP message with 4-byte >> addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with >> value 0x10 and an INTERVAL_TIME TLV with value 0x01. >> >> >> >> Compression >> ----------- >> >> The message always starts with the schema number (maybe a two-byte >> schema number would be better to allow versioning?) >> >> # 42 >> >> Add compressed msg-size to message. >> >> # xx xx >> >> If the msg-flags and msg-addr-length field is specified in the schema, >> skip them. Otherwise add them to the message >> >> # (none in this example) >> >> Add all optional message header fields that are marked in the flags and >> are not already defined in the schema. >> >> # 12 34 (sequence number value) >> >> Add a bitfield with one bit for each Optional Message TLV. Add another >> bit if TLVs follow that are not present in the Schema. >> >> # 80 ( 1st optional message TLV is present, no "other TLVs") > > So this Schema is limited to 4 known optionals and 4 uknown, do I make > sense, and could it itself be extendable, > > What is the 1st optional message TLV value? I think not given > >> >> Add all mandatory and all selected optional TLVs to the message. Leave >> out all fields that can be reconstructed from the Schema. > > What are the fields that can be reconstructed by Schema 42, was is > described here or its pre-configured > >> >> # 10 (value of VALIDITY-TIME TLV) >> # 01 (value of INTERVAL-TIME TLV) >> >> If there are other TLVs (not described in the schema), add the number of >> bytes needed to describe them and the TLVs itself >> >> # (none in this example) >> >> >> >> Result >> ------ >> >> The complete message (without the address block and its TLVs has been >> reduced from >> > > So I understand you input is for;The Schema part of TLV block > compress-describe > >> # 00 yy yy 53 01 12 34 (message header) >> # 00 08 (tlv block length) >> # 01 10 01 10 (VALIDITY-TIME 0x10) >> # 00 10 01 01 (INTERVAL-TIME 0x01) >> >> to >> >> # 00 xx xx 12 34 80 10 01 >> > > So is that the validity time is mandatory and interval time is > optional, and both are known to schema 42? > > As it was mentioned before in AODVv2 discussions the tradeoffs [1] of > positional and non-positional. It makes the description of > non-positional format message but in a positional format message by > schema way this will help for reduce processing which I like that :) > > Thanks, I think it is good idea, if I misunderstood please advise, > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg14756.html > > AB > From abdussalambaryun@gmail.com Wed Jan 23 16:07:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC7021F8A52 for ; Wed, 23 Jan 2013 16:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxO7KGIJ3ZQ1 for ; Wed, 23 Jan 2013 16:07:43 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5992421F8877 for ; Wed, 23 Jan 2013 16:07:43 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id bi5so5076354pad.13 for ; Wed, 23 Jan 2013 16:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bvQ8qy8YmFo5tVrcM6j5SMKYLK4LIrZRs4mQmntzbrA=; b=K/9E05ohMcmP41jm2D7lxdgcnkGcI+peHxvFyuj+4TTb/KX29bC0dLANwrgXtcNmqa Ku89whljoot0vHiu9SxbDWRCyBmBocGZrn2Ckz2+d2xqaEkG+jIUi/bpCpe3ss+lmhwz qpfK1Eov/cPAtgSkNC4jfv7ITYNfoSeBlLd0+0yiToHwex+eevHUySnnzWYQFFnk2vzn GDFmccGkguTkJBIe/iNysl0Sqld1hffYhnYBy38VA9TgvCk2CWNii0WCvlReZIxppwI6 UDRrrXJFfWm4xSKpKPSirFIR/3yFcy7bxSdS4Eb7fbQeD33iQqUDJCx1zofTNpm3M3Cr G9Rg== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr98119pbc.67.1358986063105; Wed, 23 Jan 2013 16:07:43 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 16:07:43 -0800 (PST) In-Reply-To: References: <50FFCA3A.5030009@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 01:07:43 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 00:07:44 -0000 sorry not reduce lifetime; > schema way this will help for reduce processing and lifetime, this schema way will help for reduce processing and increase lifetime for constraint devices, AB From trac+manet@trac.tools.ietf.org Wed Jan 23 16:47:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653B021F84E0 for ; Wed, 23 Jan 2013 16:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERackUUVAj6s for ; Wed, 23 Jan 2013 16:47:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 89C6B21F84DE for ; Wed, 23 Jan 2013 16:47:37 -0800 (PST) Received: from localhost ([127.0.0.1]:32807 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyAyZ-0000qN-Sw; Thu, 24 Jan 2013 01:47:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Thu, 24 Jan 2013 00:47:31 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/17#comment:1 Message-ID: <081.424e22f8b0cc48767e7ea8c01bc5a38b@trac.tools.ietf.org> References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #17: Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 00:47:38 -0000 #17: Proposed Reactive Protocols' Alternative Message Formats Comment (by abdussalambaryun@gmail.com): Maybe another alternative way; (d) is to use RFC5444 in the non-positional format method, and to use a Schema-base Compression/decompression either for the Reactive Protocol's messages, or for general messages, see below link http://www.ietf.org/mail-archive/web/manet/current/msg14827.html AB -- ----------------------------------------+-------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: RFC5444, Address TLVs | ----------------------------------------+-------------------------------- Ticket URL: manet From sratliff@cisco.com Wed Jan 23 19:21:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7141221F8518 for ; Wed, 23 Jan 2013 19:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXVAG8EZqJNt for ; Wed, 23 Jan 2013 19:21:53 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7901B21F84D8 for ; Wed, 23 Jan 2013 19:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5393; q=dns/txt; s=iport; t=1358997713; x=1360207313; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nbG5khelQWBl7kDnmHBuNYH+YLay3+x388LwySqBNbE=; b=XO/f1Mp90UxV68yhfHNU8UjXV72zJcL1hT/HqMCwIUPW97XpTd0lx3ze MFT1Fh2U9FeC0qr13Fsl41RcLl1sGTSjwzaFPxK4riYW4KSgJMZeCnALM 9+JbDyYmp3AUlwncDcpdm9Ay0wXurkA2YlbPHoZ/hoqFsN/lY0SNcZ1SH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFmnAFGtJV2Z/2dsb2JhbABEvkkWc4IfAQEEAQEBawsQAgEIDhQdByEGCxQRAgQOBQiIAAMPDLNpDYlVjASEDmEDiCyMCo0NhRKCdYIk X-IronPort-AV: E=Sophos;i="4.84,525,1355097600"; d="scan'208,217";a="167204084" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jan 2013 03:21:53 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0O3LqX0027460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 03:21:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 21:21:52 -0600 From: "Stan Ratliff (sratliff)" To: Joseph Macker Thread-Topic: [manet] Ideas about a schema-based compression/decompression for RFC5444 Thread-Index: AQHN+bKOkjwaMrbwTEupE0J76M1L95hX2MwAgABcSoA= Date: Thu, 24 Jan 2013 03:21:52 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFB72E@xmb-aln-x03.cisco.com> References: <50FFCA3A.5030009@fkie.fraunhofer.de> <50FFCEA1.70307@fkie.fraunhofer.de> <50FFD1A4.7040907@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.215] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFB72Exmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 03:21:54 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFB72Exmbalnx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Stan On Jan 23, 2013, at 4:51 PM, Joseph Macker wrote: I, for one, like the idea of considering and discussing how to properly int= egrate concepts of schema-based compression. On Wed, Jan 23, 2013 at 4:42 PM, Joseph Macker > wrote: On Wed, Jan 23, 2013 at 7:03 AM, Henning Rogge > wrote: On 01/23/2013 12:57 PM, Abdussalam Baryun wrote: Ok so this schema can be used for all MANET protocols that use 5444 including OSRv2, am I right, please advise, Yes, that is the plan. I think it might allow us to focus on clean protocols during the design whi= le being able to get more compact byte encoding on deployment level. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 68= 5 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFB72Exmbalnx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable +1 

Stan

On Jan 23, 2013, at 4:51 PM, Joseph Macker wrote:

I, for one, like the idea of considering and discussing how to properl= y integrate concepts of schema-based compression.


On Wed, Jan 23, 2013 at 4:42 PM, Joseph Macker <= span dir=3D"ltr"> <jpmacker@gmail.= com> wrote:



On Wed, Jan 23, 2013 at 7:03 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 01/23/2013 12:57 PM, Abdussalam Baryun wrote:
Ok so this schema can be used for all MANET protocols that use 5444
including OSRv2, am I right, please advise,

Yes, that is the plan.

I think it might allow us to focus on clean protocols during the design whi= le being able to get more compact byte encoding on deployment level.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fki= e.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFB72Exmbalnx03ciscoc_-- From henning.rogge@fkie.fraunhofer.de Wed Jan 23 23:55:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93E21F89BA for ; Wed, 23 Jan 2013 23:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDIlCde82BAG for ; Wed, 23 Jan 2013 23:55:34 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 24ED121F89A4 for ; Wed, 23 Jan 2013 23:55:34 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyHem-0000BD-0U; Thu, 24 Jan 2013 08:55:32 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyHel-0005PU-U5; Thu, 24 Jan 2013 08:55:31 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Jan 2013 08:55:31 +0100 Message-ID: <5100E8EB.9040300@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 08:55:23 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50FFCA3A.5030009@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070705000406070902060406" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16562/Thu Jan 24 00:40:16 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 1ca316a575d9c470f4f93eca24f19e92 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 07:55:35 -0000 --------------ms070705000406070902060406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/24/2013 12:58 AM, Abdussalam Baryun wrote: > Hi Henning, > > I like the idea/plan and hope it can be in I-D in future, this input > to contribute to its discussions. If this schema is general for all, I > think we may need the schema to be flexible/extendable because may > have reasonable limitation (4 opt tlvs only), not sure, but > comments/questions inline, It already does support more than 4 optional TLVs. > On 1/23/13, Henning Rogge wrote: >> This is an example for a "schema based compression" I am thinking abou= t. >> I use NHDP without the address part as an example to describe the idea= =2E >> >> This example is not complete, because I still have to work through the= >> details of the address block. >> >> >> Schema Number: 42 > > This Schema number will be for All MANET Router Protocols using > RFC5444, not only for NHDP, am I correct, This number is a locally (at the deployment level) assigned number which = defines one of the schemas used in the deployment. Making the schema=20 number independent from the message type allows for multiple schema for=20 a single message type. One IPv4 schema and one IPv6 schema for example,=20 or maybe a new schema to get a smooth upgrade path from an older one. > All protocol message type in MANET will need to identify its mandatory > and optional TLVs to the 42 Schema, No. You only should to put in the TLVs your local deployment really USE. If=20 you do not use MPRs, you should not add the TLV to the schema. > (the addresses block as you said > will be design in the Schema but later) I will send a full example including address block later today. >> ----------------- >> Header: >> * Message Type 0 >> * Optional Fields: mhashoplimit, mhassequencenumber >> * Address Length: 4 >> * Hop Limit 1 >> >> Mandatory Message TLVs: >> * TLV type 1 >> *-- extension type 0 >> *-- value length 1 >> >> Optional Message TLVs: >> * TLV type 0: >> *-- extension type 0 >> *-- value length 1 > > What was the example optional message TLV, not sure, I would suggest reading RFC 5497 (TimeTLV) and RFC6130 (NHDP): http://tools.ietf.org/html/rfc5497#section-9.2 http://tools.ietf.org/html/rfc6130#section-18.4 >> Add a bitfield with one bit for each Optional Message TLV. Add another= >> bit if TLVs follow that are not present in the Schema. >> >> # 80 ( 1st optional message TLV is present, no "other TLVs") > > So this Schema is limited to 4 known optionals and 4 uknown, do I make > sense, and could it itself be extendable, No, it does not... its just padded with enough 0 bits to a smooth number = of bytes. In this case its only one byte, because you need zero bits to encode the = number of Type-1 TLVs (because there is ALWAYS exactly one) and one bit=20 to encode the number of Type-0 TLVs. I will see that it becomes more clear in the full example. > What is the 1st optional message TLV value? I think not given > >> >> Add all mandatory and all selected optional TLVs to the message. Leave= >> out all fields that can be reconstructed from the Schema. > > What are the fields that can be reconstructed by Schema 42, was is > described here or its pre-configured Maybe you should read the schema description again and then look into=20 RFC5444 to see which fields you can take from the schema. >> # 10 (value of VALIDITY-TIME TLV) >> # 01 (value of INTERVAL-TIME TLV) Here are the TLV values (one for the mandatory TLV, one for the optional = one) you were looking for. > So is that the validity time is mandatory and interval time is > optional, and both are known to schema 42? Yes. The idea behind the "optional TLVs" is that you can encode them very=20 efficiently because they are mentioned in the schema. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070705000406070902060406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjQwNzU1MjlaMCMGCSqGSIb3DQEJBDEWBBSiE4pm3bcJ+ooCJ5hh4H23aajgyTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAeWaJ1PeYfQr/iUXvc/OsHciQhgItVgFkode1+WgCF/wC zK5Zzdm2KELu9D2/neT0Ez+MNbIbSLIpj+iNkyWsH2iRTgFUyKG9r9Z0bQwI94H9GDaf1mgP DKabuAzhpO9TX7FAKlgPDeycWacSq0LTUgtuXNVV9IzhxL781jRTd0FZU4PLLp+SeVzPJzMb xg9mPlJkwWMh897GSD5xt7GJhKBHRt4raPnXbGIsGS1iMbjiPpgS4630albrYlErMDLSm0Zy RqgPbTqrOurA5YeMbIUIV+9GheTOp+B8n795fez77AqeQR1DXdaQ7X3T3xsuNSPMrD/WMn7m wHPmgjF8/QAAAAAAAA== --------------ms070705000406070902060406-- From rick.taylor@cassidian.com Thu Jan 24 01:57:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAD521F867A for ; Thu, 24 Jan 2013 01:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5e7KGXZPqvI for ; Thu, 24 Jan 2013 01:57:54 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8451B21F8447 for ; Thu, 24 Jan 2013 01:57:51 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 24 Jan 2013 10:57:49 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 24 Jan 2013 10:58:03 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jan 2013 10:57:48 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jan 2013 10:57:48 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 09:57:48 +0000 From: "Taylor, Rick" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Ideas about a schema-based compression/decompression for RFC5444 Thread-Index: AQHN+V117aGTl6ZezEuu8HjaZbyJ1JhYPXwg Date: Thu, 24 Jan 2013 09:57:47 +0000 Message-ID: References: <0f5c6a6e-587c-4c9e-84a1-e8a3b70ad012@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <0f5c6a6e-587c-4c9e-84a1-e8a3b70ad012@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2013 09:57:48.0735 (UTC) FILETIME=[441ADCF0:01CDFA19] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19582.003 X-TM-AS-Result: No--27.199300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:57:55 -0000 I'm a definite +1 on this. Having implemented RFC5444 parsers/generators,= I can definitely see the improvement schema compression could make. There are obviously some finer details that need to be thought about, but i= f you'd like some assistance, Henning, please let me know. I would imagine a definition, compatible with RFC5444 = definition would be the correct place to start... This proposal may go a long way to resolve the black/white positional TLV a= rguments not only for in-progress protocols, but also stop future groups ha= ving the same discussions again. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 23 January 2013 11:32 > To: manet@ietf.org > Subject: [manet] Ideas about a schema-based compression/decompression for > RFC5444 > > This is an example for a "schema based compression" I am thinking about. > I use NHDP without the address part as an example to describe the idea. > > This example is not complete, because I still have to work through the > details of the address block. > > > Schema Number: 42 > ----------------- > Header: > * Message Type 0 > * Optional Fields: mhashoplimit, mhassequencenumber > * Address Length: 4 > * Hop Limit 1 > > Mandatory Message TLVs: > * TLV type 1 > *-- extension type 0 > *-- value length 1 > > Optional Message TLVs: > * TLV type 0: > *-- extension type 0 > *-- value length 1 > > > > Compression idea > ---------------- > > Remove everything from RFC5444 message that can be reconstructed from > Schema. Use bitfields to describe which optional TLVs are present in > TLV-block. > > The message to be compressed is a normal NHDP message with 4-byte > addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with > value 0x10 and an INTERVAL_TIME TLV with value 0x01. > > > > Compression > ----------- > > The message always starts with the schema number (maybe a two-byte > schema number would be better to allow versioning?) > > # 42 > > Add compressed msg-size to message. > > # xx xx > > If the msg-flags and msg-addr-length field is specified in the schema, > skip them. Otherwise add them to the message > > # (none in this example) > > Add all optional message header fields that are marked in the flags and > are not already defined in the schema. > > # 12 34 (sequence number value) > > Add a bitfield with one bit for each Optional Message TLV. Add another > bit if TLVs follow that are not present in the Schema. > > # 80 ( 1st optional message TLV is present, no "other TLVs") > > Add all mandatory and all selected optional TLVs to the message. Leave > out all fields that can be reconstructed from the Schema. > > # 10 (value of VALIDITY-TIME TLV) > # 01 (value of INTERVAL-TIME TLV) > > If there are other TLVs (not described in the schema), add the number of > bytes needed to describe them and the TLVs itself > > # (none in this example) > > > > Result > ------ > > The complete message (without the address block and its TLVs has been > reduced from > > # 00 yy yy 53 01 12 34 (message header) > # 00 08 (tlv block length) > # 01 10 01 10 (VALIDITY-TIME 0x10) > # 00 10 01 01 (INTERVAL-TIME 0x01) > > to > > # 00 xx xx 12 34 80 10 01 > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Thu Jan 24 02:02:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD9B21F84C9 for ; Thu, 24 Jan 2013 02:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmoGhh+LhKao for ; Thu, 24 Jan 2013 02:02:39 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6629421F84BC for ; Thu, 24 Jan 2013 02:02:39 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyJdm-0001VY-O9 for manet@ietf.org; Thu, 24 Jan 2013 11:02:38 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyJdm-0000Yp-LV for manet@ietf.org; Thu, 24 Jan 2013 11:02:38 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Jan 2013 11:02:38 +0100 Message-ID: <510106BD.3020503@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 11:02:37 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> <081.424e22f8b0cc48767e7ea8c01bc5a38b@trac.tools.ietf.org> In-Reply-To: <081.424e22f8b0cc48767e7ea8c01bc5a38b@trac.tools.ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060202050803060909040103" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16562/Thu Jan 24 00:40:16 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 3227f0690b92e74c5d151b48a7980dce Subject: Re: [manet] #17: Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:02:40 -0000 --------------ms060202050803060909040103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/24/2013 01:47 AM, manet issue tracker wrote: > #17: Proposed Reactive Protocols' Alternative Message Formats > > > Comment (by abdussalambaryun@gmail.com): > > Maybe another alternative way; (d) is to use RFC5444 in the non-posit= ional > format method, and to use a Schema-base Compression/decompression eit= her > for the Reactive Protocol's messages, or for general messages, see be= low > link I don't think putting my idea at this state into the Issue-Tracker is=20 helpful. Especially not with this title. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060202050803060909040103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjQxMDAyMzdaMCMGCSqGSIb3DQEJBDEWBBRUrKvItXuycUYHJSq/cGDyYKmYAzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAXqWXztD4k+yIAYZeUqXSnIaOWJ2UpUTH4Ts2r9buu/9D SA+Dm5ojgUZ03xVUbNZXTjnA8UjX+pIzPKmr61LcnA9mWMFp/XoO8rncwzbxQRafVNyS/Uck +OJrVWxtIlI7S+NteMQC3ZmyBxmR3S3OxV3Ao/IkznytHGCjkOH8fKNC+GV13L5BaPP+Pkb4 zUoF79Yj9MN2EEQKjaxikd0K05YKbcmFFids6fWviFrhgSiFUVmFcnFdisln8X4f+B/wD323 MxNddJsxRJH7hSUpcEzVBFkCKuKShP0iwTrAN6rppMVxna+yJDFfEo3fVlLxRGUzlFFt3YPN fpUbb6/PwgAAAAAAAA== --------------ms060202050803060909040103-- From abdussalambaryun@gmail.com Thu Jan 24 03:06:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9A921F86CC for ; Thu, 24 Jan 2013 03:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymkWugmhLsvr for ; Thu, 24 Jan 2013 03:06:33 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8721F8691 for ; Thu, 24 Jan 2013 03:06:33 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so3993356pbc.21 for ; Thu, 24 Jan 2013 03:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ThIWs8l6LPv+7y+58mb5HRhFnWzJLIWcYMOH/Lkqn6s=; b=lGm/swpeaXc1THYyMhoUdElURSml9yFaPbBES1d7B9Mzvf9nTEGa4KaoMglXDQMn2j 1Yim4kBjZdlO4eI1l3YIeyUcJZrv77nUDBwdehqRn0oPShevZWA4YN1Z6PM6TgTBY9KI OKxCqkI4f7ZwdeKAiDRLBu4BVfDU9uoTDZPA6Uwy5MTtPdIZPBsvRq46+g10kS9O9w0+ fj89HNUlP4ZMJAsgahX0rPT4J5K55e8ht9JwsRxk8CTf4M17RTINi0fBCsi9qeTKdmIT 1cDG4QaxwtXPBAeLGlG1GnZamAWWtNNAm/+axHjJqoKitpe7dU7wSdDlAvRag0uZZljh 2PLg== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr3609978pbc.140.1359025592934; Thu, 24 Jan 2013 03:06:32 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 03:06:32 -0800 (PST) In-Reply-To: <5100E8EB.9040300@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> <5100E8EB.9040300@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 12:06:32 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:06:33 -0000 Thanks Henning for answers, some more discussion in line; On 1/24/13, Henning Rogge wrote: > On 01/24/2013 12:58 AM, Abdussalam Baryun wrote: >> Hi Henning, >> >> I like the idea/plan and hope it can be in I-D in future, this input >> to contribute to its discussions. If this schema is general for all, I >> think we may need the schema to be flexible/extendable because may >> have reasonable limitation (4 opt tlvs only), not sure, but >> comments/questions inline, > > It already does support more than 4 optional TLVs. > >> On 1/23/13, Henning Rogge wrote: >>> This is an example for a "schema based compression" I am thinking about. >>> I use NHDP without the address part as an example to describe the idea. >>> >>> This example is not complete, because I still have to work through the >>> details of the address block. >>> >>> >>> Schema Number: 42 >> >> This Schema number will be for All MANET Router Protocols using >> RFC5444, not only for NHDP, am I correct, > > This number is a locally (at the deployment level) assigned number which > defines one of the schemas used in the deployment. Making the schema > number independent from the message type allows for multiple schema for > a single message type. One IPv4 schema and one IPv6 schema for example, > or maybe a new schema to get a smooth upgrade path from an older one. Yes I agree, but also the one schema can be used for different protocols' messages, this is what I understood from your plan, did I understand the plan? > >> All protocol message type in MANET will need to identify its mandatory >> and optional TLVs to the 42 Schema, > > No. > > You only should to put in the TLVs your local deployment really USE. If > you do not use MPRs, you should not add the TLV to the schema. > You mentioned the plan is for all prtocols in MANET, not sure why the condition now, >>> ----------------- >>> Header: >>> * Message Type 0 >>> * Optional Fields: mhashoplimit, mhassequencenumber >>> * Address Length: 4 >>> * Hop Limit 1 >>> >>> Mandatory Message TLVs: >>> * TLV type 1 >>> *-- extension type 0 >>> *-- value length 1 >>> >>> Optional Message TLVs: >>> * TLV type 0: >>> *-- extension type 0 >>> *-- value length 1 > > >>> Add a bitfield with one bit for each Optional Message TLV. Add another >>> bit if TLVs follow that are not present in the Schema. >>> >>> # 80 ( 1st optional message TLV is present, no "other TLVs") >> 80 (Byte) = (1000) (0000) bitfield does that make sense, I may be misunderstood! >> So this Schema is limited to 4 known optionals and 4 uknown, do I make >> sense, and could it itself be extendable, > > No, it does not... its just padded with enough 0 bits to a smooth number > of bytes. You mentioned bitfield with one bit for each Opt-Msg-TLV, then you mention to add another *bit* (i.e. I think you meant another fieldbit not bit, am I right) for unknown/non-present. I understood that each field is 4 bits. (please note I feel it maybe a stupid question but need to understand) > > In this case its only one byte, because you need zero bits to encode the > number of Type-1 TLVs (because there is ALWAYS exactly one) and one bit > to encode the number of Type-0 TLVs. > > I will see that it becomes more clear in the full example. Thanks > >> What is the 1st optional message TLV value? I think not given >> >>> > > The idea behind the "optional TLVs" is that you can encode them very > efficiently because they are mentioned in the schema. I agree AB From abdussalambaryun@gmail.com Thu Jan 24 03:07:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9C21F866D for ; Thu, 24 Jan 2013 03:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5D1bGhB7XL7 for ; Thu, 24 Jan 2013 03:07:20 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59621F8843 for ; Thu, 24 Jan 2013 03:07:05 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id bg2so5424732pad.4 for ; Thu, 24 Jan 2013 03:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=CdlkwrUIGAGefsRO3/eqPsOUM3rjVulDbePkTeXPqUs=; b=aQ8P4fPS2m5vJZNylMIkXaX5Zx6rK56/WBK0UHm5Yr8p5fClklTKgX8HDai8FDuZOU sTnOyj8JxEFI5nRnNkkO1WUGRBJM8tr3RbcoVXRAEdhX8TbwtMbbTviUST5oQYWTH5b5 pU+sbDS847eye2onWlpZo8ul+6CUzHhUoF1bcJFQheDZRzx/2NIxUHDFJmzBkIAIn/5t 62jDxIGTJkLbi3DmTikVKcCdQNAXnQEILFoA6nrDsv79vDTKVGZOhgeoKYfRC1pYrobS Xn31Qat52S0CAzmhMhDtJnUSSmgBL0IIhtLJtTnI5adj821vPSoFcWLshXZDJbMjAeth McGQ== MIME-Version: 1.0 X-Received: by 10.66.72.226 with SMTP id g2mr3510181pav.67.1359025625315; Thu, 24 Jan 2013 03:07:05 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 03:07:05 -0800 (PST) In-Reply-To: References: <0f5c6a6e-587c-4c9e-84a1-e8a3b70ad012@SUCNPTEXC01.COM.AD.UK.DS.CORP> Date: Thu, 24 Jan 2013 12:07:05 +0100 Message-ID: From: Abdussalam Baryun To: "Taylor, Rick" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:07:21 -0000 +1 AB On 1/24/13, Taylor, Rick wrote: > I'm a definite +1 on this. Having implemented RFC5444 parsers/generator= s, > I can definitely see the improvement schema compression could make. > > There are obviously some finer details that need to be thought about, but= if > you'd like some assistance, Henning, please let me know. > > I would imagine a definition, compatible with RFC544= 4 > definition would be the correct place to start... > > This proposal may go a long way to resolve the black/white positional TLV > arguments not only for in-progress protocols, but also stop future groups > having the same discussions again. > > Rick Taylor > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Henning Rogge >> Sent: 23 January 2013 11:32 >> To: manet@ietf.org >> Subject: [manet] Ideas about a schema-based compression/decompression fo= r >> RFC5444 >> >> This is an example for a "schema based compression" I am thinking about. >> I use NHDP without the address part as an example to describe the idea. >> >> This example is not complete, because I still have to work through the >> details of the address block. >> >> >> Schema Number: 42 >> ----------------- >> Header: >> * Message Type 0 >> * Optional Fields: mhashoplimit, mhassequencenumber >> * Address Length: 4 >> * Hop Limit 1 >> >> Mandatory Message TLVs: >> * TLV type 1 >> *-- extension type 0 >> *-- value length 1 >> >> Optional Message TLVs: >> * TLV type 0: >> *-- extension type 0 >> *-- value length 1 >> >> >> >> Compression idea >> ---------------- >> >> Remove everything from RFC5444 message that can be reconstructed from >> Schema. Use bitfields to describe which optional TLVs are present in >> TLV-block. >> >> The message to be compressed is a normal NHDP message with 4-byte >> addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with >> value 0x10 and an INTERVAL_TIME TLV with value 0x01. >> >> >> >> Compression >> ----------- >> >> The message always starts with the schema number (maybe a two-byte >> schema number would be better to allow versioning?) >> >> # 42 >> >> Add compressed msg-size to message. >> >> # xx xx >> >> If the msg-flags and msg-addr-length field is specified in the schema, >> skip them. Otherwise add them to the message >> >> # (none in this example) >> >> Add all optional message header fields that are marked in the flags and >> are not already defined in the schema. >> >> # 12 34 (sequence number value) >> >> Add a bitfield with one bit for each Optional Message TLV. Add another >> bit if TLVs follow that are not present in the Schema. >> >> # 80 ( 1st optional message TLV is present, no "other TLVs") >> >> Add all mandatory and all selected optional TLVs to the message. Leave >> out all fields that can be reconstructed from the Schema. >> >> # 10 (value of VALIDITY-TIME TLV) >> # 01 (value of INTERVAL-TIME TLV) >> >> If there are other TLVs (not described in the schema), add the number of >> bytes needed to describe them and the TLVs itself >> >> # (none in this example) >> >> >> >> Result >> ------ >> >> The complete message (without the address block and its TLVs has been >> reduced from >> >> # 00 yy yy 53 01 12 34 (message header) >> # 00 08 (tlv block length) >> # 01 10 01 10 (VALIDITY-TIME 0x10) >> # 00 10 01 01 (INTERVAL-TIME 0x01) >> >> to >> >> # 00 xx xx 12 34 80 10 01 >> >> >> Henning Rogge >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > The information contained within this e-mail and any files attached to th= is > e-mail is private and in addition may include commercially sensitive > information. The contents of this e-mail are for the intended recipient o= nly > and therefore if you wish to disclose the information contained within th= is > e-mail or attached files, please contact the sender prior to any such > disclosure. If you are not the intended recipient, any disclosure, copyin= g > or distribution is prohibited. Please also contact the sender and inform > them of the error and delete the e-mail, including any attached files fro= m > your system. Cassidian Limited, Registered Office : Quadrant House, Celti= c > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Jan 24 03:11:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E529021F895B for ; Thu, 24 Jan 2013 03:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg7zInvdPY5L for ; Thu, 24 Jan 2013 03:11:31 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 58FC421F8959 for ; Thu, 24 Jan 2013 03:11:31 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so5458998pac.15 for ; Thu, 24 Jan 2013 03:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=84iArbJxL2iH4wpx0Ek3HdzTfqzwSayMe8I/ucEtnpk=; b=XLS/aRkL45L0ggylXPo6g1iWDiseFrmk66NnokPxaDn83PH2uxqX0kYEgo/DrK+pQa FTOl3EYsQY41TgbGra8IPp/wBXSunWCPyhgg/7zIqFwebEnae/iF6lPV2P5jSMGvBWQp I38lTFpY/QIpM6q7wEoyrDpg8pOWSNNC9orDTPSQSv6mWiU0xybmQjAbUTUnDN2LChqq u4fGtIf1yKjBYimB86ajVSbC2M04DRnNli9uOYOBacu7DdYhKdfVqcFqcNsRwczR8SLg U2tD5nqMSxQMeLsZRI5mba3SE12J1M4JtYkYI2RjbF2WrncL3b/MZwt8Ulhd/gV2Jc+x XkDw== MIME-Version: 1.0 X-Received: by 10.69.0.40 with SMTP id av8mr3716066pbd.117.1359025891037; Thu, 24 Jan 2013 03:11:31 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 03:11:30 -0800 (PST) In-Reply-To: <510106BD.3020503@fkie.fraunhofer.de> References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> <081.424e22f8b0cc48767e7ea8c01bc5a38b@trac.tools.ietf.org> <510106BD.3020503@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 12:11:30 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] #17: Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:11:32 -0000 Please note that you mentioned that the Plan of the Schema [1] is for all MANET protocols, so this reactive is one important, [1] http://www.ietf.org/mail-archive/web/manet/current/msg14824.html I don't think I misunderstood, AB On 1/24/13, Henning Rogge wrote: > On 01/24/2013 01:47 AM, manet issue tracker wrote: >> #17: Proposed Reactive Protocols' Alternative Message Formats >> >> >> Comment (by abdussalambaryun@gmail.com): >> >> Maybe another alternative way; (d) is to use RFC5444 in the >> non-positional >> format method, and to use a Schema-base Compression/decompression >> either >> for the Reactive Protocol's messages, or for general messages, see >> below >> link > > I don't think putting my idea at this state into the Issue-Tracker is > helpful. > > Especially not with this title. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From henning.rogge@fkie.fraunhofer.de Thu Jan 24 03:32:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424D021F8487 for ; Thu, 24 Jan 2013 03:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SxlCLblvPx2 for ; Thu, 24 Jan 2013 03:32:27 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB5C21F8484 for ; Thu, 24 Jan 2013 03:32:27 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyL2g-0006ZR-Eh; Thu, 24 Jan 2013 12:32:26 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyL2g-00031C-By; Thu, 24 Jan 2013 12:32:26 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Jan 2013 12:32:25 +0100 Message-ID: <51011BC5.5090300@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 12:32:21 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <50FFCA3A.5030009@fkie.fraunhofer.de> <5100E8EB.9040300@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070600020300080101010203" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16562/Thu Jan 24 00:40:16 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8463f811132de2515b9cdd797fc5085e Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:32:28 -0000 --------------ms070600020300080101010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/24/2013 12:06 PM, Abdussalam Baryun wrote: >> This number is a locally (at the deployment level) assigned number >> which defines one of the schemas used in the deployment. Making the >> schema number independent from the message type allows for multiple >> schema for a single message type. One IPv4 schema and one IPv6 >> schema for example, or maybe a new schema to get a smooth upgrade >> path from an older one. > > Yes I agree, but also the one schema can be used for different > protocols' messages, this is what I understood from your plan, did I > understand the plan? Unlikely... because different protocol messages have very different conte= nt. You will most likely specify several schema with different IDs, (at least) one for each RFC5444 message in use. >> You only should to put in the TLVs your local deployment really >> USE. If you do not use MPRs, you should not add the TLV to the >> schema. >> > > You mentioned the plan is for all prtocols in MANET, not sure why > the condition now, The more "optional" and "variable" things you have in your schema, the less specific it is and the larger the compressed messages will become. >>>> Add a bitfield with one bit for each Optional Message TLV. Add >>>> another bit if TLVs follow that are not present in the Schema. >>>> >>>> # 80 ( 1st optional message TLV is present, no "other TLVs") >>> > > 80 (Byte) =3D (1000) (0000) bitfield > > does that make sense, I may be misunderstood! 0x80 (byte) =3D (1) (0) (padding=3D000000) You need one bit to encode the presence/absence of a TLV that can be=20 present only once (or not at all). You don't need any bit at all to encode the presence of a mandatory TLV=20 that can be present only once. The final "0" bit says "no uncompressed TLVs are following". So the example use 2 bits of the byte, the rest is padding. >>> So this Schema is limited to 4 known optionals and 4 uknown, do I >>> make sense, and could it itself be extendable, >> >> No, it does not... its just padded with enough 0 bits to a smooth >> number of bytes. > > You mentioned bitfield with one bit for each Opt-Msg-TLV, then you > mention to add another *bit* (i.e. I think you meant another > fieldbit not bit, am I right) for unknown/non-present. I understood > that each field is 4 bits. (please note I feel it maybe a stupid > question but need to understand) It could happen that the message contains a TLV that is not mentioned in the Schema at all. The last bit activates some kind of "add a real uncompressed TLV block" feature at the end. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070600020300080101010203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjQxMTMyMjRaMCMGCSqGSIb3DQEJBDEWBBRPofgXgmmwHhk+sFkxMnNL6UfQYzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAp4xNYhgovZGRcorUze2rIU+ef5FVfGnhBralz2oBydb6 mUn/vFG5phJRvFbYuvnt7+nDyhxdThGDmtSjR1iNiCyYI7zoMwWRnpXBUQ8E9h+LnIWHwuUT OfTN/ecBY969mxL0yAUJ/sIEVL5B5y0OoTSSI9F+ttwdrK2AJlxkwnT7u1bXUCB25GLw1/b0 kilwURSWYIYbJm5q5dnmAx7d654ugKcQFP+Gn3G29m4/1nfbGxnWXEWuOsQzBAx5nV72jrZy q+aFFyhS/Qfcm46Vc0r/Dcg7ssdJ45bCbXudmKBbcsEfpbG34TJ+E3pCZQovDLJxzlTM+8vL Y14GrkXQpQAAAAAAAA== --------------ms070600020300080101010203-- From abdussalambaryun@gmail.com Thu Jan 24 04:37:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF121F8A4A for ; Thu, 24 Jan 2013 04:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsBjZcCHogEP for ; Thu, 24 Jan 2013 04:37:04 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id C5F1F21F84CC for ; Thu, 24 Jan 2013 04:37:04 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so4234960dae.35 for ; Thu, 24 Jan 2013 04:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=P4CaMr9FGHHk/KvxfOcYpIwpPXtTp1h8Ue4PQ9m0PhM=; b=KW2sWp/Og3IoookoYVFBjpxJ0cKFXEBj9H7xTR42KL3fs6SHtBr+ICmLlfm1U/cMsF kOMbASQ/4/LhYemHDwhPAT47zlW62t2cStx9mcr4alRPMKhW2KHkLfCo6zzZGbqNFGVM rFkVSAtOTqixO8dfWLKfrH4KWyjztQDtvx+TMjlciDTSGUFXu5nd1fndnzFlkz+x56fN Mr+Di38MaI/N1nVCmxoozJ6xFI2QQLqEwQ+lv0cCMjR1SkqZMob9LwnUBhBLBKiDeTns g2dKPQ25WVwrlb/4mTDeZqAVX7v7gr8F05bnLymRktAEv7fmPOATsF6vZS3jk947dAHb P0uQ== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr4310953pbc.140.1359031024540; Thu, 24 Jan 2013 04:37:04 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 04:37:04 -0800 (PST) In-Reply-To: <51011BC5.5090300@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> <5100E8EB.9040300@fkie.fraunhofer.de> <51011BC5.5090300@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 13:37:04 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 12:37:06 -0000 Thanks Henning, now I understand this, waiting for your next examples ;) All the best AB On 1/24/13, Henning Rogge wrote: > On 01/24/2013 12:06 PM, Abdussalam Baryun wrote: >>> This number is a locally (at the deployment level) assigned number >>> which defines one of the schemas used in the deployment. Making the >>> schema number independent from the message type allows for multiple >>> schema for a single message type. One IPv4 schema and one IPv6 >>> schema for example, or maybe a new schema to get a smooth upgrade >>> path from an older one. >> >> Yes I agree, but also the one schema can be used for different >> protocols' messages, this is what I understood from your plan, did I >> understand the plan? > > Unlikely... because different protocol messages have very different > content. > > You will most likely specify several schema with different IDs, (at > least) one for each RFC5444 message in use. > >>> You only should to put in the TLVs your local deployment really >>> USE. If you do not use MPRs, you should not add the TLV to the >>> schema. >>> >> >> You mentioned the plan is for all prtocols in MANET, not sure why >> the condition now, > > The more "optional" and "variable" things you have in your schema, the > less specific it is and the larger the compressed messages will become. > >>>>> Add a bitfield with one bit for each Optional Message TLV. Add >>>>> another bit if TLVs follow that are not present in the Schema. >>>>> >>>>> # 80 ( 1st optional message TLV is present, no "other TLVs") >>>> >> >> 80 (Byte) =3D (1000) (0000) bitfield >> >> does that make sense, I may be misunderstood! > > 0x80 (byte) =3D (1) (0) (padding=3D000000) > > You need one bit to encode the presence/absence of a TLV that can be > present only once (or not at all). > > You don't need any bit at all to encode the presence of a mandatory TLV > that can be present only once. > > The final "0" bit says "no uncompressed TLVs are following". > > So the example use 2 bits of the byte, the rest is padding. > >>>> So this Schema is limited to 4 known optionals and 4 uknown, do I >>>> make sense, and could it itself be extendable, >>> >>> No, it does not... its just padded with enough 0 bits to a smooth >>> number of bytes. >> >> You mentioned bitfield with one bit for each Opt-Msg-TLV, then you >> mention to add another *bit* (i.e. I think you meant another >> fieldbit not bit, am I right) for unknown/non-present. I understood >> that each field is 4 bits. (please note I feel it maybe a stupid >> question but need to understand) > > It could happen that the message contains a TLV that is not mentioned in > the Schema at all. The last bit activates some kind of "add a real > uncompressed TLV block" feature at the end. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From henning.rogge@fkie.fraunhofer.de Thu Jan 24 06:53:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD5221F8A64 for ; Thu, 24 Jan 2013 06:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp-mjUUETNlh for ; Thu, 24 Jan 2013 06:53:38 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB221F8A42 for ; Thu, 24 Jan 2013 06:53:37 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyOBM-0006FC-HK for manet@ietf.org; Thu, 24 Jan 2013 15:53:36 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyOBM-0008Pk-Ee for manet@ietf.org; Thu, 24 Jan 2013 15:53:36 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Jan 2013 15:53:36 +0100 Message-ID: <51014AEB.6070402@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 15:53:31 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070909020800030806070700" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16562/Thu Jan 24 00:40:16 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 892e1ee4af9f25813a69f4246b22de0a Subject: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 14:53:39 -0000 --------------ms070909020800030806070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable RFC5444 Schema Compression V2 =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=3D=3D=3D Changes since V1: - restructured text to make it easier to read - added compression for address-TLVs - simplified Schema description (no more differentiation between mandatory and optional TLVs) - added explanation for TLVs schema fields Compression idea ---------------- Describe the typical content of a RFC5444 message in your deployment=20 with a Schema. Remove everything from the RFC5444 message that can be constructed from=20 Schema. Use bitfields to describe how many TLVs of each kind are present = in a TLV-block and their data. Schema content -------------- Schema field values can a list of possible values (the list can contain=20 a single value) or an interval of numbers. Schema fields can be empty=20 when the field is not restricted by the Schema in any ways and has=20 always to be fully transmitted over the network. Fields for Message Header: - each of the fields of the Message Headers schema describes one of the=20 possible fields described in RFC5444 chapter 5.2 Fields for TLVs: - "quantity" limits the number of times a TLV can be present in a=20 TLV-block. The VALIDITY_TIME TLV is mandatory for all NHDP messages and=20 can only be present once, so its quantity is "1". The INTERVAL_TIME TLV=20 is optional for NHDP messages, but must not be there more than once, so=20 its quantity is "0-1". - "extension type" sets the extension type of the TLV if known. - "value length" restricts the length of the TLVs value (to a range or a = fixed length). - "value" restricts the value itself of the TLV. Example schema -------------- Schema Number 42 Message Header: * Type 0 * MHasOrig: 0 * MHasHopLimit: 1 * MHasHopCount: 0 * MHasSeqnum: 1 * Address Length: 4 * Originator Address * Hop Limit 1 * Hop Count * Sequence Number Message TLVs: * TLV type 0: (INTERVAL_TIME) +-- quantity 0-1 +-- extension type 0 +-- value length 1 +-- value | * TLV type 1 (VALIDITY_TIME) +-- quantity 1 +-- extension type 0 +-- value length 1 +-- value Addresses Block TLVs: * TLV type 2 (LOCAL_IF) +-- quantity +-- extension type 0 +-- value length 1 +-- value 0-1 | * TLV type 3 (LINK_STATUS) +-- quantity +-- extension type 0 +-- value length 1 +-- value 0-2 | + TLV type 4 (OTHER_NEIGHBOR) +-- quantity +-- extension type 0 +-- value length 1 +-- value 0-1 Example message for compression ------------------------------- The message to be compressed in this example is a NHDP message: - 4-byte addresses, - hoplimit 1, - sequence number 0x1234 - an INTERVAL_TIME Message-TLV with value 0x01 - a VALDIITY_TIME Message-TLV with value 0x10 - an address block with the IP's 10.0.0.1, 10.0.0.2 and 10.0.0.3 - 3-byte head, no prefixes - 10.0.0.1 has a LOCAL_IF Address-TLV with value 0x00 - 10.0.0.2/3 have a LINK_STATUS Address-TLV with value 0x01 and 0x02 - 10.0.0.2/3 have an OTHER_NEIGHBOR Address-TLV with value 0x01 and 0x00 Compression description ----------------------- The message always starts with the schema number. # 42 Add compressed msg-size to message. # xx xx If the msg-flags AND msg-addr-length field is specified in the schema,=20 skip them. Otherwise add them to the message # (none in this example) Add all optional message header fields (Originator, Hoplimit, Hopcount,=20 Sequence Number) that are marked in the flags and are not already=20 defined in the schema. # 12 34 (sequence number value) Add a bitfield with as many bits for each TLV as needed to encode the=20 quantity of it (no bit necessary for one fixed quantity, one bit for=20 0-1, ...). Append another bit that encodes if 'other TLVs' will follow=20 the compressed ones. binary: # 1 0 ( 1*INTERVAL_TIME, 1*VALDIITY_TIME, no "other TLVs") in bytes: # 80 Add all present TLVs to the compressed message. Leave out all fields=20 that can be reconstructed from the Schema. Shorten each TLVs remaining=20 fields (except tlv-flags) into bitfield as long as the possible=20 combinations need. Only compress value if can be expressed in less than=20 8 bits (padd with zero-bits before the value if not). # 01 (value of INTERVAL-TIME TLV) # 10 (value of VALIDITY-TIME TLV) If there are other TLVs (not described in the schema), add the number of = bytes needed to describe them (2 byte length field similar to a TLV=20 block) and the TLVs itself (uncompressed). # (none in this example) Add the address-block to the compressed message. The number of addresses can give an additional restriction to the=20 minimum/maximum index the TLVs can have and the maximum quantity of the=20 TLVs. Maximum quantity in this example is 3. # 03 80 03 10 00 00 01 02 03 Add a bitfield with as many bits for each TLV as needed to encode the=20 quantity of it (no bit necessary for one fixed quantity, one bit for=20 0-1, ...). Append another bit that encodes if 'other TLVs' will follow=20 the compressed ones. binary: # 01 01 01 0 (1*LOCAL_IF, 1*LINK_STATUS, 1*OTHER_NEIGHBOR, no other TLVs)= or in bytes: # 54 Add all present TLVs to the compressed message. Leave out all fields=20 that can be reconstructed from the Schema. Shorten each TLVs remaining=20 fields (except tlv-flags) into bitfield as long as the possible=20 combinations need. Only compress value if can be expressed in less than=20 8 bits (padd with zero-bits before the value if not). binary: # 01010000 01 0 (LOCAL_IF flags, index-start and value) # 00110100 10 11 01 10 (LINK_STATUS flags, index-start, index-end and=20 value 1/2) # 00110100 10 11 1 0 (OTHER_NEIGHBOR flags, index-start, index-end and=20 value 1/2) in bytes: # 50 40 # 34 b6 # 34 b8 If there are other TLVs (not described in the schema), add the number of = bytes needed to describe them (2 byte length field similar to a TLV=20 block) and the TLVs itself (uncompressed). # (none in this example) Result ------ The complete message has been reduced from # 00 00 2f 53 01 12 34 (message header) # 00 08 (message-tlv block length) # 00 10 01 01 (INTERVAL-TIME 0x01) # 01 10 01 10 (VALIDITY-TIME 0x10) # 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1/2/3, no prefixes) # 00 13 (address-tlv block length) # 02 50 01 01 00 (LOCAL_IF index=3D1 0x00) # 03 34 02 03 01 01 02 (LINK_STATUS index=3D2-3 0x01/0x02) # 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=3D2-3 0x01/0x00) (47 bytes) to # 42 00 18 12 34 (message header) # 80 01 10 (message tlvs) # 03 80 03 10 00 00 01 02 03 (address block) # 54 50 40 34 b6 34 b8 (address tlvs) (24 bytes) Comments -------- A packet-level schema entry should be added to this concept. Maybe the schema number should be a two-byte identifier? I think there could be some more compression if the Schema includes a=20 "mandatory prefix" for all addresses (or maybe a list of them?). This=20 would help to compress both the originator address and the prefix fields = in address blocks. In theory there are a few wasted bits here and there, but I decided NOT=20 to do any bit-shifting on data which is 1 byte or larger. One problem I ignored in this version is the presence of multiple TLVs=20 of the same type attached to the same address. Maybe the Schema=20 "quantity" field for address TLVs should be interpreted as "quantity per = address?" A great addition to this idea would be a protocol for requesting unknown = schema from your neighbor. And a program that scans a RFC5444 stream and = suggests a schema based on the watched messages. --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070909020800030806070700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjQxNDUzMzRaMCMGCSqGSIb3DQEJBDEWBBQpyc9ixCvcoLmSGs6LT79X3vndxDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAbKx3jE9HvWzIqLkB9S7BYNqUl8ZToZtfLifRjRMl+ADm ZOki5fYuO//eI4agj9F/wItvutNk9OOUoXvogBJVZCfLzigcId4dsw74DUDqLJ/zQbqyAnI/ jSdgIGRuBgc6xAodPsNkkIo71+DWVtx3SscVeevhxKrWDdJx6MuTW23brPKCqZ8DV1OLszUM ZOl5yUUmuHyi4dkN0PjmmphsOFSVDTRhQfYgyiMJrhlhnKWSHmPYKq816ou0BW9RA318FmQL 2W6rYTpPaXiJ2YuD3TeH1rbwLuvI/0x8q9QxT4fcx2fE+ON6SpmBxft6j/3R7EvsRYGxWyoZ VrO3YmgVhwAAAAAAAA== --------------ms070909020800030806070700-- From Chris.Dearlove@baesystems.com Thu Jan 24 08:48:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516D921F872D for ; Thu, 24 Jan 2013 08:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-hmgVuccFAl for ; Thu, 24 Jan 2013 08:48:34 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6B21F86F4 for ; Thu, 24 Jan 2013 08:48:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="257467012" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Jan 2013 16:48:25 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0OGmOa1007810 for ; Thu, 24 Jan 2013 16:48:24 GMT X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="4328546" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 24 Jan 2013 16:48:24 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Thu, 24 Jan 2013 16:48:24 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN+kKjqBkFl6yaQEqIsMfk71Dq05hYrXlw Date: Thu, 24 Jan 2013 16:48:24 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> In-Reply-To: <51014AEB.6070402@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:48:35 -0000 How is it proposed to put this compressed format on the wire (or over the a= ir more likely)? You can't just put it on the manet protocol/port, as that would be parsed a= s 5444, which it isn't. Approaches I could see include (but this is not an exhaustive list; new, be= tter, ideas welcome). - This is for specialised uses (e.g. as in something like 6LOWPAN). - On some other port (I doubt you'd get another protocol). - Describing a new 5444 version 1. It's a bit of an abuse, as it's not exactly a version, but maybe. I'd also want to be convinced that these schemas allow extensions without changing the schema. For example suppose I decide to add to either NHDP's HELLO message or OLSRv2's TC message that these could advertise blacklisted addresses (whatever that means) using a BLACKLIST TLV. That needs to be possible without updating the schema to know about that TLV. (Why? TLVs in the private/experimental space for a start.) [This may be obvious, I haven't had the time to study this yet.] --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 24 January 2013 14:54 To: manet@ietf.org Subject: [manet] RFC5444 schema-based compression V2 RFC5444 Schema Compression V2 =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=3D=3D=3D Changes since V1: - restructured text to make it easier to read - added compression for address-TLVs - simplified Schema description (no more differentiation between mandatory and optional TLVs) - added explanation for TLVs schema fields Compression idea ---------------- Describe the typical content of a RFC5444 message in your deployment=20 with a Schema. Remove everything from the RFC5444 message that can be constructed from=20 Schema. Use bitfields to describe how many TLVs of each kind are present=20 in a TLV-block and their data. Schema content -------------- Schema field values can a list of possible values (the list can contain=20 a single value) or an interval of numbers. Schema fields can be empty=20 when the field is not restricted by the Schema in any ways and has=20 always to be fully transmitted over the network. Fields for Message Header: - each of the fields of the Message Headers schema describes one of the=20 possible fields described in RFC5444 chapter 5.2 Fields for TLVs: - "quantity" limits the number of times a TLV can be present in a=20 TLV-block. The VALIDITY_TIME TLV is mandatory for all NHDP messages and=20 can only be present once, so its quantity is "1". The INTERVAL_TIME TLV=20 is optional for NHDP messages, but must not be there more than once, so=20 its quantity is "0-1". - "extension type" sets the extension type of the TLV if known. - "value length" restricts the length of the TLVs value (to a range or a=20 fixed length). - "value" restricts the value itself of the TLV. Example schema -------------- Schema Number 42 Message Header: * Type 0 * MHasOrig: 0 * MHasHopLimit: 1 * MHasHopCount: 0 * MHasSeqnum: 1 * Address Length: 4 * Originator Address * Hop Limit 1 * Hop Count * Sequence Number Message TLVs: * TLV type 0: (INTERVAL_TIME) +-- quantity 0-1 +-- extension type 0 +-- value length 1 +-- value | * TLV type 1 (VALIDITY_TIME) +-- quantity 1 +-- extension type 0 +-- value length 1 +-- value Addresses Block TLVs: * TLV type 2 (LOCAL_IF) +-- quantity +-- extension type 0 +-- value length 1 +-- value 0-1 | * TLV type 3 (LINK_STATUS) +-- quantity +-- extension type 0 +-- value length 1 +-- value 0-2 | + TLV type 4 (OTHER_NEIGHBOR) +-- quantity +-- extension type 0 +-- value length 1 +-- value 0-1 Example message for compression ------------------------------- The message to be compressed in this example is a NHDP message: - 4-byte addresses, - hoplimit 1, - sequence number 0x1234 - an INTERVAL_TIME Message-TLV with value 0x01 - a VALDIITY_TIME Message-TLV with value 0x10 - an address block with the IP's 10.0.0.1, 10.0.0.2 and 10.0.0.3 - 3-byte head, no prefixes - 10.0.0.1 has a LOCAL_IF Address-TLV with value 0x00 - 10.0.0.2/3 have a LINK_STATUS Address-TLV with value 0x01 and 0x02 - 10.0.0.2/3 have an OTHER_NEIGHBOR Address-TLV with value 0x01 and 0x00 Compression description ----------------------- The message always starts with the schema number. # 42 Add compressed msg-size to message. # xx xx If the msg-flags AND msg-addr-length field is specified in the schema,=20 skip them. Otherwise add them to the message # (none in this example) Add all optional message header fields (Originator, Hoplimit, Hopcount,=20 Sequence Number) that are marked in the flags and are not already=20 defined in the schema. # 12 34 (sequence number value) Add a bitfield with as many bits for each TLV as needed to encode the=20 quantity of it (no bit necessary for one fixed quantity, one bit for=20 0-1, ...). Append another bit that encodes if 'other TLVs' will follow=20 the compressed ones. binary: # 1 0 ( 1*INTERVAL_TIME, 1*VALDIITY_TIME, no "other TLVs") in bytes: # 80 Add all present TLVs to the compressed message. Leave out all fields=20 that can be reconstructed from the Schema. Shorten each TLVs remaining=20 fields (except tlv-flags) into bitfield as long as the possible=20 combinations need. Only compress value if can be expressed in less than=20 8 bits (padd with zero-bits before the value if not). # 01 (value of INTERVAL-TIME TLV) # 10 (value of VALIDITY-TIME TLV) If there are other TLVs (not described in the schema), add the number of=20 bytes needed to describe them (2 byte length field similar to a TLV=20 block) and the TLVs itself (uncompressed). # (none in this example) Add the address-block to the compressed message. The number of addresses can give an additional restriction to the=20 minimum/maximum index the TLVs can have and the maximum quantity of the=20 TLVs. Maximum quantity in this example is 3. # 03 80 03 10 00 00 01 02 03 Add a bitfield with as many bits for each TLV as needed to encode the=20 quantity of it (no bit necessary for one fixed quantity, one bit for=20 0-1, ...). Append another bit that encodes if 'other TLVs' will follow=20 the compressed ones. binary: # 01 01 01 0 (1*LOCAL_IF, 1*LINK_STATUS, 1*OTHER_NEIGHBOR, no other TLVs) or in bytes: # 54 Add all present TLVs to the compressed message. Leave out all fields=20 that can be reconstructed from the Schema. Shorten each TLVs remaining=20 fields (except tlv-flags) into bitfield as long as the possible=20 combinations need. Only compress value if can be expressed in less than=20 8 bits (padd with zero-bits before the value if not). binary: # 01010000 01 0 (LOCAL_IF flags, index-start and value) # 00110100 10 11 01 10 (LINK_STATUS flags, index-start, index-end and=20 value 1/2) # 00110100 10 11 1 0 (OTHER_NEIGHBOR flags, index-start, index-end and=20 value 1/2) in bytes: # 50 40 # 34 b6 # 34 b8 If there are other TLVs (not described in the schema), add the number of=20 bytes needed to describe them (2 byte length field similar to a TLV=20 block) and the TLVs itself (uncompressed). # (none in this example) Result ------ The complete message has been reduced from # 00 00 2f 53 01 12 34 (message header) # 00 08 (message-tlv block length) # 00 10 01 01 (INTERVAL-TIME 0x01) # 01 10 01 10 (VALIDITY-TIME 0x10) # 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1/2/3, no prefixes) # 00 13 (address-tlv block length) # 02 50 01 01 00 (LOCAL_IF index=3D1 0x00) # 03 34 02 03 01 01 02 (LINK_STATUS index=3D2-3 0x01/0x02) # 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=3D2-3 0x01/0x00) (47 bytes) to # 42 00 18 12 34 (message header) # 80 01 10 (message tlvs) # 03 80 03 10 00 00 01 02 03 (address block) # 54 50 40 34 b6 34 b8 (address tlvs) (24 bytes) Comments -------- A packet-level schema entry should be added to this concept. Maybe the schema number should be a two-byte identifier? I think there could be some more compression if the Schema includes a=20 "mandatory prefix" for all addresses (or maybe a list of them?). This=20 would help to compress both the originator address and the prefix fields=20 in address blocks. In theory there are a few wasted bits here and there, but I decided NOT=20 to do any bit-shifting on data which is 1 byte or larger. One problem I ignored in this version is the presence of multiple TLVs=20 of the same type attached to the same address. Maybe the Schema=20 "quantity" field for address TLVs should be interpreted as "quantity per=20 address?" A great addition to this idea would be a protocol for requesting unknown=20 schema from your neighbor. And a program that scans a RFC5444 stream and=20 suggests a schema based on the watched messages. --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From hrogge@googlemail.com Thu Jan 24 09:09:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3D21F89C0 for ; Thu, 24 Jan 2013 09:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adxaOYLXradQ for ; Thu, 24 Jan 2013 09:09:40 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0807721F8994 for ; Thu, 24 Jan 2013 09:09:39 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id ji2so5396818bkc.1 for ; Thu, 24 Jan 2013 09:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KwA1Um97H9FTljUSakAB3GLyJvLLrrMisbF0D2DeMeI=; b=ROOegNF2WAUGM8mh/VdPCcnYawMCmFXhwT7i9mshbUZLon2L2EyRocpWH63E/2qpOv lmZ6mL5c7HI6rCObEpDkeh8yMixOlzrlmkPSUuLjdQEhZ5z6aGyZwUf/DecIj2S3nlUZ 8LGOZ/HSvex7z/u59nFyAvwyJ3hMiBV/sq4tnzGvJKW14fvu8IegaoUzTAjRv3mTKBPS egHCHsXKJ3yPjlO36a+UUAbKyA0RnxrYEoseRGO/V6m0f1Xpl2ho749KeYYHHfEg4930 L5k5eX+z0JMMANXUnEyhlNzq+GiEvUFbBi870VPLGloJh9NVZGAf8OohELu3QFXPGO6V Mxrw== X-Received: by 10.152.109.146 with SMTP id hs18mr2594826lab.8.1359047378890; Thu, 24 Jan 2013 09:09:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Thu, 24 Jan 2013 09:09:18 -0800 (PST) In-Reply-To: References: <51014AEB.6070402@fkie.fraunhofer.de> From: Henning Rogge Date: Thu, 24 Jan 2013 18:09:18 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:09:41 -0000 On Thu, Jan 24, 2013 at 5:48 PM, Dearlove, Christopher (UK) wrote: > How is it proposed to put this compressed format on the wire (or over the air more likely)? > > You can't just put it on the manet protocol/port, as that would be parsed as 5444, which it isn't. > > Approaches I could see include (but this is not an exhaustive list; new, better, ideas welcome). > - This is for specialised uses (e.g. as in something like 6LOWPAN). We could consider it as some kind of "linklayer compressor/decompressor" in some cases, which means the UDP packets of RFC5444 get compressed and decompressed by some device driver. ROHC (Robust Header Compression) is similar I think. > - On some other port (I doubt you'd get another protocol). > - Describing a new 5444 version 1. It's a bit of an abuse, as it's not > exactly a version, but maybe. In a certain sense it is... it contains the same "internal structure", it has just been transformed into a different representation. If there would be a protocol to query for an unknown schema, we could even have nodes learning from each other what to do with this packets as long as they are marked correctly. > I'd also want to be convinced that these schemas allow extensions > without changing the schema. For example suppose I decide to add > to either NHDP's HELLO message or OLSRv2's TC message that these > could advertise blacklisted addresses (whatever that means) using > a BLACKLIST TLV. That needs to be possible without updating the > schema to know about that TLV. (Why? TLVs in the private/experimental > space for a start.) Yes, it does. In each compressed TLV-Block, after all the bits in the bitfield that mark the presence of certain compressed TLVs there is a final bit that says "uncompressed TLVs follow". If this bit is a "1", you will process the compressed TLVs first, then read a normal 2-byte length field and start processing uncompressed TLVs. This way we have another "upgrade path" from one schema to the other one. Of course when you do so, you might also start working on a new schema for your deployment too. But I think its mandatory that there is a way to add things that are not described in the schema. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Thu Jan 24 10:23:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6F21F857D for ; Thu, 24 Jan 2013 10:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTL3RFpVOSUY for ; Thu, 24 Jan 2013 10:23:04 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 60F6C21F844A for ; Thu, 24 Jan 2013 10:23:04 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so5697299pad.10 for ; Thu, 24 Jan 2013 10:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=8c9HeWtS1PS7snZW3AcEny6Ar/RWJK+N7O5kO0/wsa0=; b=pShCxlI0YJrjjYyiHhNJtMkg53QhPwhymLEFpKj9XxjBykJgngpZP55APcE4Hxy7+i 8cSydn+rN+ZHUPoh12g3uNMWsKhLjgg+07NCarrFQCzM0Ikr1ugGGAAlXQFnFcwHrCiq j7LkX4BnCm1tBjTfodC2mJP2c2ccBlavFDMLTyTbni1042Rq3+zFlavWi1yDomWHDdm9 /xkVsGve1mgbK9c3l1vVuPrmjSRPJK01yS/8G/liqurEQ3C4T05B6/sCRVQlGa7V3tft hYJ0qxL1qhP6zLQO03sEplgHZPlCMqs6LN0DgAwyHOy8yxv/OmasOoHhsHE26eDUqiAH D4uA== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr7263700pbc.140.1359051784136; Thu, 24 Jan 2013 10:23:04 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 10:23:04 -0800 (PST) In-Reply-To: <50FFCA3A.5030009@fkie.fraunhofer.de> References: <50FFCA3A.5030009@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 19:23:04 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:23:05 -0000 On 1/23/13, Henning Rogge wrote: > # 00 yy yy 53 01 12 34 (message header) > # 00 08 (tlv block length) > # 01 10 01 10 (VALIDITY-TIME 0x10) > # 00 10 01 01 (INTERVAL-TIME 0x01) > > to > > # 00 xx xx 12 34 80 10 01 > So it will be: # 42 xx xx 12 34 80 10 01 As from the other thread below; http://www.ietf.org/mail-archive/web/manet/current/msg14840.html AB From abdussalambaryun@gmail.com Thu Jan 24 10:32:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F258B21F8506 for ; Thu, 24 Jan 2013 10:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-MHv+miIzBT for ; Thu, 24 Jan 2013 10:32:39 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id A7CAD21F84CC for ; Thu, 24 Jan 2013 10:32:35 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id rp2so5600215pbb.15 for ; Thu, 24 Jan 2013 10:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FttYxh8S0Q5IoDYmpmrOy1MSs6FLk2mVOkxq/KwI/Gc=; b=bJ0S2roRYvogYQpgz+Nr2KoCCGq1RNqwDSOlZnQEBxt8QYHk28IHkVjy18xMYmbXoJ mqyJqvm+uYvs33hv2nAk+LMZKpkKtDT/46hno9zEqWo78sRENOgVAz1TvumR+hWdTXeO JgpI+9vaUG0cZQq6MR5nwEZoSKDJe+jvxbCw45Jlwlr/8BmN1PDYLAq+WvBnHNatkz1n il0W+dSY9C0HbOq7LHRXKb1dL2Tr3YbrsyA9qxmT8p3K1e7BHVD7KvbSWtkNvVklIw1V BjyapvNHDRKzMTlQ9m/G5lE0nRS8Gj5hJ/EsemmDIRFzzfqOAjUbJJ8ssihWhD5oY+j1 w33Q== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr7501531pbc.70.1359052355373; Thu, 24 Jan 2013 10:32:35 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 10:32:35 -0800 (PST) In-Reply-To: <51014AEB.6070402@fkie.fraunhofer.de> References: <51014AEB.6070402@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 19:32:35 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:32:40 -0000 On 1/24/13, Henning Rogge wrote: > # 00 00 2f 53 01 12 34 (message header) > # 00 08 (message-tlv block length) > # 00 10 01 01 (INTERVAL-TIME 0x01) > # 01 10 01 10 (VALIDITY-TIME 0x10) > # 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1/2/3, no prefixes) > # 00 13 (address-tlv block length) > # 02 50 01 01 00 (LOCAL_IF index=1 0x00) > # 03 34 02 03 01 01 02 (LINK_STATUS index=2-3 0x01/0x02) > # 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=2-3 0x01/0x00) > > (47 bytes) > > to > > # 42 00 18 12 34 (message header) > # 80 01 10 (message tlvs) > # 03 80 03 10 00 00 01 02 03 (address block) > # 54 50 40 34 b6 34 b8 (address tlvs) > > (24 bytes) If compressed then, Why not this way as in your previous example, # 42 00 18 12 34 80 01 10 03 80 03 10 00 00 01 02 03 54 50 40 34 b6 34 b8 The Schema takes them together or in parts as you done, not sure :( Please advise, AB From abdussalambaryun@gmail.com Thu Jan 24 10:43:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB03421F8652 for ; Thu, 24 Jan 2013 10:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFjp4fE8vbVb for ; Thu, 24 Jan 2013 10:43:37 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 342BA21F8650 for ; Thu, 24 Jan 2013 10:43:37 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so5696155pac.15 for ; Thu, 24 Jan 2013 10:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zephFYjrseimRJoK3OY+5dv1iLrlrCEJWbW9EcaHFSs=; b=KWMF2ONAG37Cddwl6MuGW4bcFAfNWe+mVMuFp/hheStE52VghgAPl6YMBPo6VB3eSG ArbNVp13yG6oAzrIEBqLCLV0kbQ6ibScMbDcNC0/cBH+0w/J+QWiJ1DOZNkYSULaWtFF leUAvVOW8bPxNsPi1AMYXpttzIPsLRHK5aDWFz4z/Wu4sK270lZP3ZnXfhkjmhF9ABEC IZvO6mOofVLiFM42+Xrf4EWDpqxeNX8sasdeqg2Zo/ek3H1n7m0BmPl78octvwAcIkLP kzqK8mILWXYQE6EsCkxL/j1SJX86hn+1HB/88/g7zq/hR+yFuauP657JZj2sQ+cgR4We vOpA== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr7637987pbb.43.1359053017008; Thu, 24 Jan 2013 10:43:37 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 10:43:36 -0800 (PST) In-Reply-To: <51014AEB.6070402@fkie.fraunhofer.de> References: <51014AEB.6070402@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 19:43:36 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:43:37 -0000 Hi Henning, comments below; On 1/24/13, Henning Rogge wrote: > RFC5444 Schema Compression V2 > ============================= > > Changes since V1: > - restructured text to make it easier to read > - added compression for address-TLVs > - simplified Schema description > (no more differentiation between mandatory and optional TLVs) > - added explanation for TLVs schema fields > > Comments > -------- > > A packet-level schema entry should be added to this concept. > Not sure what you mean, I thought the Schema is only for messages, addresses and tlvs, why you including the packet? > Maybe the schema number should be a two-byte identifier? > Yes I agree, because to cover all future extensions and updates. > One problem I ignored in this version is the presence of multiple TLVs > of the same type attached to the same address. Maybe the Schema > "quantity" field for address TLVs should be interpreted as "quantity per > address?" That is why I mentioned before there was limitation of TLV and asked if there is possibility to adjust. I think it is important to consider this issue, AB From abdussalambaryun@gmail.com Thu Jan 24 12:36:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43D311E80A6 for ; Thu, 24 Jan 2013 12:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxUD-xfto3s2 for ; Thu, 24 Jan 2013 12:36:18 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2E11E80A4 for ; Thu, 24 Jan 2013 12:36:18 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id fb10so5767630pad.30 for ; Thu, 24 Jan 2013 12:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=2WN+lJCQxmWqI9+QIvrN8MHYSwNKaiEM1PUhVPPUZbc=; b=cSXGRQmVVAIR8JEex6jSVMmBg4Vh4BgoA16pTtQW/2mT3wow3brUfJPF02tLGj9kra cdKnu1dvWsSz5tzvdGpiVzDOTjIIK6by5MkpuIPLwb2Fiz6DeEaWDNtKi6kRdcHQefO2 O+l89K1k/JQakIk1LOj780FVPTiyZOZiPD0Is1rUSXxTwmzuJvsbYBjH0Tii3HjDCuR6 5j89pAszW9pptIX+ZzF2doV6uWfOn4h7OeTRAEDkNjxriJ9W/vLdh+783Nx4M1sRpgWp IEVajl/TMvE4xLw7xDBy+CwcMf60Vopb64bDQgf1+7+sOzBMeYxqVKVds6fZE9tOUeti Pzsw== MIME-Version: 1.0 X-Received: by 10.66.78.100 with SMTP id a4mr7959601pax.4.1359059778033; Thu, 24 Jan 2013 12:36:18 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 12:36:17 -0800 (PST) In-Reply-To: References: <51014AEB.6070402@fkie.fraunhofer.de> Date: Thu, 24 Jan 2013 21:36:17 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:36:19 -0000 On 1/24/13, Dearlove, Christopher (UK) wrot= e: > You can't just put it on the manet protocol/port, as that would be parsed= as > 5444, which it isn't. A different parse compression, I think this schema is not for 5444 packet, but 5444 messages > > Approaches I could see include (but this is not an exhaustive list; new, > better, ideas welcome). > - This is for specialised uses (e.g. as in something like 6LOWPAN). > - On some other port (I doubt you'd get another protocol). > - Describing a new 5444 version 1. It's a bit of an abuse, as it's not > exactly a version, but maybe. It is a second version of the parse and compression done before, > > I'd also want to be convinced that these schemas allow extensions > without changing the schema. For example suppose I decide to add > to either NHDP's HELLO message or OLSRv2's TC message that these > could advertise blacklisted addresses (whatever that means) using > a BLACKLIST TLV. That needs to be possible without updating the > schema to know about that TLV. (Why? TLVs in the private/experimental > space for a start.) I agree that it is better as you mentioned AB > > [This may be obvious, I haven't had the time to study this yet.] > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 24 January 2013 14:54 > To: manet@ietf.org > Subject: [manet] RFC5444 schema-based compression V2 > > RFC5444 Schema Compression V2 > =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=3D=3D=3D > > Changes since V1: > - restructured text to make it easier to read > - added compression for address-TLVs > - simplified Schema description > (no more differentiation between mandatory and optional TLVs) > - added explanation for TLVs schema fields > > > > Compression idea > ---------------- > > Describe the typical content of a RFC5444 message in your deployment > with a Schema. > > Remove everything from the RFC5444 message that can be constructed from > Schema. Use bitfields to describe how many TLVs of each kind are present > in a TLV-block and their data. > > > > Schema content > -------------- > > Schema field values can a list of possible values (the list can contain > a single value) or an interval of numbers. Schema fields can be empty > when the field is not restricted by the Schema in any ways and has > always to be fully transmitted over the network. > > > Fields for Message Header: > - each of the fields of the Message Headers schema describes one of the > possible fields described in RFC5444 chapter 5.2 > > > Fields for TLVs: > - "quantity" limits the number of times a TLV can be present in a > TLV-block. The VALIDITY_TIME TLV is mandatory for all NHDP messages and > can only be present once, so its quantity is "1". The INTERVAL_TIME TLV > is optional for NHDP messages, but must not be there more than once, so > its quantity is "0-1". > - "extension type" sets the extension type of the TLV if known. > - "value length" restricts the length of the TLVs value (to a range or a > fixed length). > - "value" restricts the value itself of the TLV. > > > > Example schema > -------------- > > Schema Number 42 > > Message Header: > * Type 0 > * MHasOrig: 0 > * MHasHopLimit: 1 > * MHasHopCount: 0 > * MHasSeqnum: 1 > * Address Length: 4 > * Originator Address > * Hop Limit 1 > * Hop Count > * Sequence Number > > Message TLVs: > * TLV type 0: (INTERVAL_TIME) > +-- quantity 0-1 > +-- extension type 0 > +-- value length 1 > +-- value > | > * TLV type 1 (VALIDITY_TIME) > +-- quantity 1 > +-- extension type 0 > +-- value length 1 > +-- value > > Addresses Block TLVs: > * TLV type 2 (LOCAL_IF) > +-- quantity > +-- extension type 0 > +-- value length 1 > +-- value 0-1 > | > * TLV type 3 (LINK_STATUS) > +-- quantity > +-- extension type 0 > +-- value length 1 > +-- value 0-2 > | > + TLV type 4 (OTHER_NEIGHBOR) > +-- quantity > +-- extension type 0 > +-- value length 1 > +-- value 0-1 > > > > Example message for compression > ------------------------------- > > The message to be compressed in this example is a NHDP message: > - 4-byte addresses, > - hoplimit 1, > - sequence number 0x1234 > > - an INTERVAL_TIME Message-TLV with value 0x01 > - a VALDIITY_TIME Message-TLV with value 0x10 > > - an address block with the IP's 10.0.0.1, 10.0.0.2 and 10.0.0.3 > - 3-byte head, no prefixes > - 10.0.0.1 has a LOCAL_IF Address-TLV with value 0x00 > - 10.0.0.2/3 have a LINK_STATUS Address-TLV with value 0x01 and 0x02 > - 10.0.0.2/3 have an OTHER_NEIGHBOR Address-TLV with value 0x01 and 0x00 > > > > Compression description > ----------------------- > > The message always starts with the schema number. > > # 42 > > Add compressed msg-size to message. > > # xx xx > > If the msg-flags AND msg-addr-length field is specified in the schema, > skip them. Otherwise add them to the message > > # (none in this example) > > Add all optional message header fields (Originator, Hoplimit, Hopcount, > Sequence Number) that are marked in the flags and are not already > defined in the schema. > > # 12 34 (sequence number value) > > Add a bitfield with as many bits for each TLV as needed to encode the > quantity of it (no bit necessary for one fixed quantity, one bit for > 0-1, ...). Append another bit that encodes if 'other TLVs' will follow > the compressed ones. > > binary: > # 1 0 ( 1*INTERVAL_TIME, 1*VALDIITY_TIME, no "other TLVs") > > in bytes: > # 80 > > Add all present TLVs to the compressed message. Leave out all fields > that can be reconstructed from the Schema. Shorten each TLVs remaining > fields (except tlv-flags) into bitfield as long as the possible > combinations need. Only compress value if can be expressed in less than > 8 bits (padd with zero-bits before the value if not). > > # 01 (value of INTERVAL-TIME TLV) > # 10 (value of VALIDITY-TIME TLV) > > If there are other TLVs (not described in the schema), add the number of > bytes needed to describe them (2 byte length field similar to a TLV > block) and the TLVs itself (uncompressed). > > # (none in this example) > > Add the address-block to the compressed message. > > The number of addresses can give an additional restriction to the > minimum/maximum index the TLVs can have and the maximum quantity of the > TLVs. Maximum quantity in this example is 3. > > # 03 80 03 10 00 00 01 02 03 > > Add a bitfield with as many bits for each TLV as needed to encode the > quantity of it (no bit necessary for one fixed quantity, one bit for > 0-1, ...). Append another bit that encodes if 'other TLVs' will follow > the compressed ones. > > binary: > # 01 01 01 0 (1*LOCAL_IF, 1*LINK_STATUS, 1*OTHER_NEIGHBOR, no other TLVs) > > or in bytes: > # 54 > > Add all present TLVs to the compressed message. Leave out all fields > that can be reconstructed from the Schema. Shorten each TLVs remaining > fields (except tlv-flags) into bitfield as long as the possible > combinations need. Only compress value if can be expressed in less than > 8 bits (padd with zero-bits before the value if not). > > binary: > # 01010000 01 0 (LOCAL_IF flags, index-start and value) > # 00110100 10 11 01 10 (LINK_STATUS flags, index-start, index-end and > value 1/2) > # 00110100 10 11 1 0 (OTHER_NEIGHBOR flags, index-start, index-end and > value 1/2) > > in bytes: > # 50 40 > # 34 b6 > # 34 b8 > > If there are other TLVs (not described in the schema), add the number of > bytes needed to describe them (2 byte length field similar to a TLV > block) and the TLVs itself (uncompressed). > > # (none in this example) > > > > Result > ------ > > The complete message has been reduced from > > # 00 00 2f 53 01 12 34 (message header) > # 00 08 (message-tlv block length) > # 00 10 01 01 (INTERVAL-TIME 0x01) > # 01 10 01 10 (VALIDITY-TIME 0x10) > # 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1/2/3, no prefixes) > # 00 13 (address-tlv block length) > # 02 50 01 01 00 (LOCAL_IF index=3D1 0x00) > # 03 34 02 03 01 01 02 (LINK_STATUS index=3D2-3 0x01/0x02) > # 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=3D2-3 0x01/0x00) > > (47 bytes) > > to > > # 42 00 18 12 34 (message header) > # 80 01 10 (message tlvs) > # 03 80 03 10 00 00 01 02 03 (address block) > # 54 50 40 34 b6 34 b8 (address tlvs) > > (24 bytes) > > > > Comments > -------- > > A packet-level schema entry should be added to this concept. > > Maybe the schema number should be a two-byte identifier? > > I think there could be some more compression if the Schema includes a > "mandatory prefix" for all addresses (or maybe a list of them?). This > would help to compress both the originator address and the prefix fields > in address blocks. > > In theory there are a few wasted bits here and there, but I decided NOT > to do any bit-shifting on data which is 1 byte or larger. > > One problem I ignored in this version is the presence of multiple TLVs > of the same type attached to the same address. Maybe the Schema > "quantity" field for address TLVs should be interpreted as "quantity per > address?" > > A great addition to this idea would be a protocol for requesting unknown > schema from your neighbor. And a program that scans a RFC5444 stream and > suggests a schema based on the watched messages. > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > ******************************************************************** > 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://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Thu Jan 24 23:28:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6821F8A8B for ; Thu, 24 Jan 2013 23:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c945gBA+9VzB for ; Thu, 24 Jan 2013 23:28:17 -0800 (PST) Received: from mail-we0-x22a.google.com (we-in-x022a.1e100.net [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E691C21F8A7B for ; Thu, 24 Jan 2013 23:28:16 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so32092wey.29 for ; Thu, 24 Jan 2013 23:28:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=bDOkpimLjfauXEk5woOgvPPFKrZ/349D+suSheAHCeY=; b=NhxejWkGU3yNFQ9VXrtnPusK4lQ51riLvgo0JliNW5goYNR5c68jMuXAIORiCnS8Td ubibJ1f65SJmyzVqIOK3+EXhxs0atg8NNLAOgu2OZj23iZi28rAsa+xAFzp1LOB+7Qx+ zMikRzwxn/senZMJc0D6WntI3z050FVzbJYouXbwetPAmpogfdZG76Am7dPrMwa90fcq fvUEovSG8vymUE4fz/PRu3pwPIAoiYIssQEbhhzf5VSFhUL0seesXL+F70scD3fIXkDo AGS5tmPWkYSLvGQJgv8PfnpgjY6sWlcX7/TMU5kHzouaFFVKTwCAKX229TjbL8RqmRDC 6/IQ== X-Received: by 10.180.92.100 with SMTP id cl4mr7010485wib.24.1359098895515; Thu, 24 Jan 2013 23:28:15 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id p2sm377229wic.7.2013.01.24.23.28.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 23:28:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 25 Jan 2013 08:28:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <39EBD8CE-AD5D-4AAF-9BDD-B520EB4BD1AE@inf-net.nl> References: <51014AEB.6070402@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl9jdYSk09n/eW44H5HTTCTkCHAur6YXCHbH7iorP664fZnaEh4ixLG1dlScLCxCRx5EKtI Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:28:17 -0000 Op 24 jan. 2013, om 18:09 heeft Henning Rogge het volgende geschreven: > On Thu, Jan 24, 2013 at 5:48 PM, Dearlove, Christopher (UK) > wrote: >> How is it proposed to put this compressed format on the wire (or over = the air more likely)? >>=20 >> You can't just put it on the manet protocol/port, as that would be = parsed as 5444, which it isn't. >>=20 >> Approaches I could see include (but this is not an exhaustive list; = new, better, ideas welcome). >> - This is for specialised uses (e.g. as in something like 6LOWPAN). >=20 > We could consider it as some kind of "linklayer > compressor/decompressor" in some cases, which means the UDP packets of > RFC5444 get compressed and decompressed by some device driver. >=20 > ROHC (Robust Header Compression) is similar I think. We could use this schema based compression along stateful compression = (send only delta's; ask for full messages if out-of-sync detected and/or = send full messages every now and then). Both on link layer, either = discovered or configured. Teco From teco@inf-net.nl Thu Jan 24 23:50:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34D21F8938 for ; Thu, 24 Jan 2013 23:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG6ky92-lsWe for ; Thu, 24 Jan 2013 23:50:24 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8421F8922 for ; Thu, 24 Jan 2013 23:50:23 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so40184wey.17 for ; Thu, 24 Jan 2013 23:50:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=6kSZlZK4qYyZRGCy5NXD+KhUeDAVF/p92NUF9gvHLJ4=; b=SlNMJav/SY+S1O56Ur3tE/mPHS8ociwSQj/2M0QqeRyJ8WyIWGVo2di0TCEKwGqvXr oxiVtvOR34KEGsIeaHkoQAX6HVmCcfibUxmYYGE16EYqYy4sF33KOeM7LuYThORJY7jQ r5KjVpW91FrMpYGnFV2MbsBmHPAIRNZKgkl2e9X22AHQb9eYKXfsoTN3u/JZ8qapzUAF 6CCOdBCutfHTzT9/fmIhd9q5fgb7Xi6M5dt7/B71SvwsEoEBXjhcX2U0pfjzXX10qV8p puBG4LhtlGD/GSq03jHywtyYGzv+TVsJ76RRNGjP1peXIP2XbqD4y7wC/Qm6dhzpX/Pc rvkQ== X-Received: by 10.180.24.9 with SMTP id q9mr7087619wif.14.1359100222566; Thu, 24 Jan 2013 23:50:22 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id fv2sm5851925wib.4.2013.01.24.23.50.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 23:50:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <51014AEB.6070402@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 08:50:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51014AEB.6070402@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlFXG2AF/Q4CW916eekXxc1Yy0TJW9T7I4XoabJSRG/mHP6BrHQ7vW/HF3HCHAJao2M34Aj Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:50:24 -0000 Op 24 jan. 2013, om 15:53 heeft Henning Rogge het volgende geschreven: > Maybe the schema number should be a two-byte identifier? It does make sense to use short fields as much as possible, that's the = goal of compression, right?=20 Having many schema's could bring high compression rates. Limitation on = schema numbers brings unneeded restrictions. So why not put integers in = variable length fields? Teco= From henning.rogge@fkie.fraunhofer.de Thu Jan 24 23:58:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63A421F84E0 for ; Thu, 24 Jan 2013 23:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEyjhvfI3fgB for ; Thu, 24 Jan 2013 23:58:33 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3AE21F8A51 for ; Thu, 24 Jan 2013 23:58:33 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyeBD-00040H-JW for manet@ietf.org; Fri, 25 Jan 2013 08:58:31 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyeBD-0003WS-Gs for manet@ietf.org; Fri, 25 Jan 2013 08:58:31 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 08:58:31 +0100 Message-ID: <51023B20.3030306@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 08:58:24 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50FFCA3A.5030009@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040505020505000205080803" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 3227f0690b92e74c5d151b48a7980dce Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:58:34 -0000 --------------ms040505020505000205080803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/24/2013 07:23 PM, Abdussalam Baryun wrote: > On 1/23/13, Henning Rogge wrote: >> # 00 yy yy 53 01 12 34 (message header) >> # 00 08 (tlv block length) >> # 01 10 01 10 (VALIDITY-TIME 0x10) >> # 00 10 01 01 (INTERVAL-TIME 0x01) >> >> to >> >> # 00 xx xx 12 34 80 10 01 >> > > So it will be: > > # 42 xx xx 12 34 80 10 01 Yes, the "00" was a leftover from V1. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040505020505000205080803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUwNzU4MjlaMCMGCSqGSIb3DQEJBDEWBBQIoYjIHiAGWZtujqCayc087xtlHjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAVTg3ut5bdavG6TTiHN45hTVq4V9U8LbNNUCyD2jJlRqz oMqFfKH931+KKBlNsrqWQng1VpXELlLEecAY+lu7h9uDkz2t6wUlaMW/i6F4IKg19vGTds8r AD5qpXOVrVXAkxvYI0d9lqRKuGpJrliM/P+0Frb3PrxXpwDB0pz8ziNR06rsUJo/bYi9kGyN Mn4/q0iwUWNGCUwO2hOMUMii344rOGp3g4b0vxVEL5+iGii/OokZQoKpQaaGt681nW3UKwKe QcSUkoPwW9zA9eOq0SdJylvPhD4lYpikNtB4IRpcLxBOOrrb48FNqKnokp31Lrly8NRplR1o UKQZeO8Z8AAAAAAAAA== --------------ms040505020505000205080803-- From henning.rogge@fkie.fraunhofer.de Fri Jan 25 00:00:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883D021F84F5 for ; Fri, 25 Jan 2013 00:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UyYIq+FXBjg for ; Fri, 25 Jan 2013 00:00:06 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 34C9321F8A52 for ; Fri, 25 Jan 2013 00:00:05 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyeCi-00043r-El; Fri, 25 Jan 2013 09:00:04 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyeCi-0003YS-C2; Fri, 25 Jan 2013 09:00:04 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 09:00:03 +0100 Message-ID: <51023B82.2030209@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 09:00:02 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <51014AEB.6070402@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020608030606010408050109" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:00:06 -0000 --------------ms020608030606010408050109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/24/2013 07:32 PM, Abdussalam Baryun wrote: > On 1/24/13, Henning Rogge wrote: > >> # 00 00 2f 53 01 12 34 (message header) >> # 00 08 (message-tlv block length) >> # 00 10 01 01 (INTERVAL-TIME 0x01) >> # 01 10 01 10 (VALIDITY-TIME 0x10) >> # 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1/2/3, no prefixes) >> # 00 13 (address-tlv block length) >> # 02 50 01 01 00 (LOCAL_IF index=3D1 0x00) >> # 03 34 02 03 01 01 02 (LINK_STATUS index=3D2-3 0x01/0x02) >> # 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=3D2-3 0x01/0x00) >> >> (47 bytes) >> >> to >> >> # 42 00 18 12 34 (message header) >> # 80 01 10 (message tlvs) >> # 03 80 03 10 00 00 01 02 03 (address block) >> # 54 50 40 34 b6 34 b8 (address tlvs) >> >> (24 bytes) > > If compressed then, Why not this way as in your previous example, > # 42 00 18 12 34 80 01 10 03 80 03 10 00 00 01 02 03 54 50 40 34 b6 34 = b8 > The Schema takes them together or in parts as you done, not sure :( The example is easier to read this way. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020608030606010408050109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUwODAwMDJaMCMGCSqGSIb3DQEJBDEWBBTRS0g+t22SWywf3qkcyRi5yma0dDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAOW+nj59EaK4uabEcifZ/SWM5uML0dgZoCWV9tATFHa+z vTFlJFnJFbknQjgR1I0xXOegILtkKXg1eOyECkygG1+UQ34ScdDmXisl3wluvR0KGRyeUt/k +fVvxChetShSPCmkOKpAoXYp0B1oJHN+Y8KPEQMMP4KY9E4rTUrQjZqsp9C43OthKwmNXSFa ARWvJJw8dN0RThUKGHEm3ohAIb7Y81+66N4eHYMCCFSC/L2K30FiaMgQMIKh6xO5MGaJw77P 9fXIW0UW4M/xe7z8OZOUTePCsC7LS1MHySlxnERHGwjuDqVkBk60VcdW8iqIP1oKAx66FV/K jannD6dySwAAAAAAAA== --------------ms020608030606010408050109-- From henning.rogge@fkie.fraunhofer.de Fri Jan 25 00:11:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAC421F8A8E for ; Fri, 25 Jan 2013 00:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O09F9uDbnY3a for ; Fri, 25 Jan 2013 00:11:55 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9609721F8A77 for ; Fri, 25 Jan 2013 00:11:53 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyeO9-0000aB-5x; Fri, 25 Jan 2013 09:11:53 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyeO9-0003wR-3F; Fri, 25 Jan 2013 09:11:53 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 09:11:52 +0100 Message-ID: <51023E44.5020509@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 09:11:48 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <51014AEB.6070402@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000904030102000103050501" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8318846d41f6f18a0ab4cdd00a4712ab Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:11:56 -0000 --------------ms000904030102000103050501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/24/2013 07:43 PM, Abdussalam Baryun wrote: > Hi Henning, > > comments below; > > On 1/24/13, Henning Rogge wrote: >> RFC5444 Schema Compression V2 >> =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=3D=3D=3D >> >> Changes since V1: >> - restructured text to make it easier to read >> - added compression for address-TLVs >> - simplified Schema description >> (no more differentiation between mandatory and optional TLVs) >> - added explanation for TLVs schema fields >> >> Comments >> -------- >> >> A packet-level schema entry should be added to this concept. >> > > Not sure what you mean, I thought the Schema is only for messages, > addresses and tlvs, why you including the packet? Because when we create a mechanism to compress TLV-blocks, we should=20 think about allowing nodes to have a schema for their packet-TLVs too,=20 so we can also compress them? >> Maybe the schema number should be a two-byte identifier? > > Yes I agree, because to cover all future extensions and updates. You can reuse schema numbers as soon as you do not use an old number=20 anymore in your deployment. If you deploy the same schemas on all nodes, = 1 byte should be enough I think. But if we want to think about using different schema's for each node, 1=20 byte will definitely not enough. >> One problem I ignored in this version is the presence of multiple TLVs= >> of the same type attached to the same address. Maybe the Schema >> "quantity" field for address TLVs should be interpreted as "quantity p= er >> address?" > > That is why I mentioned before there was limitation of TLV and asked > if there is possibility to adjust. I think it is important to consider > this issue, No, you asked about a limitation of optional TLVs based on the mistake=20 that the bitfield involved could only extend for 1 byte. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000904030102000103050501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUwODExNTBaMCMGCSqGSIb3DQEJBDEWBBSNp6I7nNno5zzRNdqSr+ltxB0kdjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAajLhngY0kI3cuNiDtYUPMcAFmzN+RHZcCaWEq7023akD r4rFrDIVbCEJ6Pt57FL19kcYLOzwr8lYIFcMwrMP7AAOJN5nZVCGtc30t9cCoKG1WQpM1OQZ XNo4kaOkddWYmwEW9ksFWmikD5Dl+D5OLyFryvhwANaXJo/xganC3/cdYbnNGiF57n+4Lejj vhixdXQmzqzu1paD+tDP9zoG1vXFLUbkY6aHu2Ur7efPEG6zXQp49OcfG2pbj9rOGEU3tG9S +yxayS2FevjmDMxFrh7Bz+X6KImV0e1JSDXeesk2nuMCBdGKtAMjiysEO38twKpQX9GvkK9f bizGwoAJ7AAAAAAAAA== --------------ms000904030102000103050501-- From henning.rogge@fkie.fraunhofer.de Fri Jan 25 00:14:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBD221F8AD4 for ; Fri, 25 Jan 2013 00:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or+ngkQkgpxQ for ; Fri, 25 Jan 2013 00:14:15 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A271621F8A8F for ; Fri, 25 Jan 2013 00:14:14 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyeQQ-0000eT-0K for manet@ietf.org; Fri, 25 Jan 2013 09:14:14 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyeQP-0003ze-Tv for manet@ietf.org; Fri, 25 Jan 2013 09:14:13 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 09:14:13 +0100 Message-ID: <51023ED4.1050902@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 09:14:12 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <51014AEB.6070402@fkie.fraunhofer.de> <39EBD8CE-AD5D-4AAF-9BDD-B520EB4BD1AE@inf-net.nl> In-Reply-To: <39EBD8CE-AD5D-4AAF-9BDD-B520EB4BD1AE@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030803020902040009090103" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e1a2c87e9561ebd0ec644701fc13d4ff Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:14:15 -0000 --------------ms030803020902040009090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/25/2013 08:28 AM, Teco Boot wrote: > > Op 24 jan. 2013, om 18:09 heeft Henning Rogge het volgende > geschreven: > >> On Thu, Jan 24, 2013 at 5:48 PM, Dearlove, Christopher (UK) >> wrote: >>> How is it proposed to put this compressed format on the wire (or >>> over the air more likely)? >>> >>> You can't just put it on the manet protocol/port, as that would >>> be parsed as 5444, which it isn't. >>> >>> Approaches I could see include (but this is not an exhaustive >>> list; new, better, ideas welcome). - This is for specialised uses >>> (e.g. as in something like 6LOWPAN). >> >> We could consider it as some kind of "linklayer >> compressor/decompressor" in some cases, which means the UDP packets >> of RFC5444 get compressed and decompressed by some device driver. >> >> ROHC (Robust Header Compression) is similar I think. > > We could use this schema based compression along stateful compression > (send only delta's; ask for full messages if out-of-sync detected > and/or send full messages every now and then). Both on link layer, > either discovered or configured. We discussed this idea here at the institute too. ROHC most deals with information flows between two points and with=20 (mostly) fixed length information blocks. I think this "only transmit delta" will be quite difficult to do, so I=20 skipped the idea and worked on something I was sure I could do it. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030803020902040009090103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUwODE0MTJaMCMGCSqGSIb3DQEJBDEWBBTwq7tnKAEM06QUMRw9d/ifnVXnETBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAWzi4MTj22CNqDibY4Q+JUABE5X/GViJ5s3gbTIWH01Rs j18k6RQMhATb6uBX/mn5QxB1SSZGCGG9qWENyjr1TjOSg50dcuhx6eED5VGAcJEFv5BKxmfI Yma6jvGCyb3T5yQ36NIPdIwTDydd8PTxU6tzsLXWD9/I9Ioy5cGYESBBDFeW/DGhX7LmAbmO PFh1nNPiNM5EmhI3DkcdKOjH0XiTx95FgEZobXbBqVQhH8XnnKVqAy7DEqiPfpQtRWAVeEXt k1SAtGqS8Fi5kSVmvSCkjhri0Gs2t1gFPCTeElERmrwVwLSU5P2l6375nNdGVwZ75CKtdV9G y0QCHHtzugAAAAAAAA== --------------ms030803020902040009090103-- From henning.rogge@fkie.fraunhofer.de Fri Jan 25 00:17:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAAE21F8682 for ; Fri, 25 Jan 2013 00:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edHewEF+0kdK for ; Fri, 25 Jan 2013 00:17:05 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6766C21F85A3 for ; Fri, 25 Jan 2013 00:17:04 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyeT9-0002IT-JM; Fri, 25 Jan 2013 09:17:03 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyeT9-00046w-Gi; Fri, 25 Jan 2013 09:17:03 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 09:17:03 +0100 Message-ID: <51023F7E.9020103@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 09:17:02 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teco Boot References: <51014AEB.6070402@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000909020603050205080303" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:17:05 -0000 --------------ms000909020603050205080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/25/2013 08:50 AM, Teco Boot wrote: > > Op 24 jan. 2013, om 15:53 heeft Henning Rogge het volgende > geschreven: > >> Maybe the schema number should be a two-byte identifier? > It does make sense to use short fields as much as possible, that's > the goal of compression, right? Having many schema's could bring high > compression rates. Limitation on schema numbers brings unneeded > restrictions. So why not put integers in variable length fields? Not sure we would normally safe that much. Less than one byte doesn't make much sense, unless you want to start=20 bitshift everything in the following data. What we could do would be to allocate the first bit as a "7 bit/15 bit"=20 switch for the schema id. If the first bit is zero, just take the first byte as the schema number. If the first bit is one, set it to zero and take the first TWO bytes as=20 the schema number. What do you think? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000909020603050205080303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUwODE3MDJaMCMGCSqGSIb3DQEJBDEWBBR7fNatATnpkmCkuhywZWcK4CX2njBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEANtV0WPun8Nbgi98ZCHGq7lQS1c3Wqx3J4iHCFdAcxEiY sTcrC56/JImgRCCRbugwEbLWH0kqH0RIakhD6UyBlygT8x/X3yvSFs0OEHu/S51lSZMe1pC3 V5HLtIw/UUraucL/JwD+tQs6C17I+R8NNcGNGVoL03h9PwLBOSzGnw+PV9XPu9xFSaIjyrPq ECnpt6mWK65IkXyyVmBaM8SbgOTqQf+jVn835VqAIMZK11ji7rfWkkmGZvcAEL3q2V0sFKGz KdRr62zZNEOCGEX3OD/fFH5UAIA9Amu4iQZ7PgLdYxj8eSeEeiDpiZDjRAYX01pM4ubOLlh1 xy30uJPZxwAAAAAAAA== --------------ms000909020603050205080303-- From henning.rogge@fkie.fraunhofer.de Fri Jan 25 00:37:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DF621F859C for ; Fri, 25 Jan 2013 00:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ9MKWmF+cjg for ; Fri, 25 Jan 2013 00:37:56 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 3A25321F85B8 for ; Fri, 25 Jan 2013 00:37:55 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TyenK-0000aG-Io for manet@ietf.org; Fri, 25 Jan 2013 09:37:54 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyenK-0004gm-G9 for manet@ietf.org; Fri, 25 Jan 2013 09:37:54 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 09:37:54 +0100 Message-ID: <51024461.2030502@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 09:37:53 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> In-Reply-To: <51023F7E.9020103@fkie.fraunhofer.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040902010306000500090308" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:37:57 -0000 --------------ms040902010306000500090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/25/2013 09:17 AM, Henning Rogge wrote: > What we could do would be to allocate the first bit as a "7 bit/15 bit"= > switch for the schema id. > > If the first bit is zero, just take the first byte as the schema number= =2E > If the first bit is one, set it to zero and take the first TWO bytes as= > the schema number. Second thought, we could use this for the message length field too. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040902010306000500090308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUwODM3NTNaMCMGCSqGSIb3DQEJBDEWBBQ0X9qSvu0pqJyPWy1/B9UBEwMBzzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAnFHCFFrVfpYIlaRRjoQAX5MWNo4sxvxP7XRg2ozq4Yqj YVz1FzW76ji4CpCiCA5W6sfMnD/V3NEGZzjT//8/yYdxRqse7fdAkv7zPSRuJvr3DWUJltoJ nTDbzRKC8WnhfXtseJGuzoeclxuXfEcKffOPF+OaVLvQWmaWmhzyGd2XKySyVlpdS00DwV4o ZXRxQoY3Iv90OIYbH7SfySk/jFyXbvCMXNwAkgXEtBnFXFSIHmoNOdE/TNfN0lE5IMG4ld5I ZBbiYqeCXTM8nf8+dfioSegjFSVaJVOiL5x+KA5zGSp3twXA8rB8pEUanIA5GHhemky8ElVK kvUGPVv/jQAAAAAAAA== --------------ms040902010306000500090308-- From abdussalambaryun@gmail.com Fri Jan 25 00:47:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE5421F8888 for ; Fri, 25 Jan 2013 00:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv6AtBjMMNAp for ; Fri, 25 Jan 2013 00:47:27 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5B21F8651 for ; Fri, 25 Jan 2013 00:47:26 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rq13so91109pbb.4 for ; Fri, 25 Jan 2013 00:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9wwrK6IrS9xoDZxZx01rZhLv3dgOwUIBueslaeCM9yU=; b=M9N8AHHTiJlGEgQPUx9wIiv/qhXVjpGt3myGCcq12UyQ+cozup62Hc8HgbuilHx14n OX1IewOXdomFZ3SacTd0WbodDZGwD4MS3CJ2AKETfPwKwmW2VR2sgCfggLhlDbUVNaYn MAGwER/xrD26bUBqduXdAgExTv3C4+CCI69A6o3I4PLDlTceFTTJ1+C3oxvlMTQvc2O1 M3/WrZGPMROQmnJLSUzUetUMF6ylgKo7Y9Wy/xbHS7ggvNHsZNzITy5SGbA5lBur5uZN 3Nzv9YyqsbO3S1XR5oLgH+z0YX3/xpa249btSyXCrfKbAyrUQerAJY8c/NAnznjx2TRW ndOw== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr12645262pbc.67.1359103646786; Fri, 25 Jan 2013 00:47:26 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 00:47:26 -0800 (PST) In-Reply-To: <51023F7E.9020103@fkie.fraunhofer.de> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 09:47:26 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:47:27 -0000 On 1/25/13, Henning Rogge wrote: > What we could do would be to allocate the first bit as a "7 bit/15 bit" > switch for the schema id. > > If the first bit is zero, just take the first byte as the schema number. > If the first bit is one, set it to zero and take the first TWO bytes as > the schema number. > > What do you think? I think that is a good choice, AB From Chris.Dearlove@baesystems.com Fri Jan 25 02:13:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B01221F86D9 for ; Fri, 25 Jan 2013 02:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-KHNF6d4mw9 for ; Fri, 25 Jan 2013 02:13:54 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1221F86D6 for ; Fri, 25 Jan 2013 02:13:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,537,1355097600"; d="scan'208";a="257607627" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Jan 2013 10:13:53 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0PADrTl011320 for ; Fri, 25 Jan 2013 10:13:53 GMT X-IronPort-AV: E=Sophos;i="4.84,537,1355097600"; d="scan'208";a="4385680" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 25 Jan 2013 10:13:52 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 25 Jan 2013 10:13:53 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN+kKjqBkFl6yaQEqIsMfk71Dq05hYrXlwgAAJGACAAR0kQA== Date: Fri, 25 Jan 2013 10:13:52 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:13:55 -0000 The linklayer concept obviously means one would have to consider 5444 packe= ts, not just messages. It could be argued to be a layer violation, but then= several things done in such circumstances could be so considered. We are in agreement on your last point. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: 24 January 2013 17:09 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet@ietf.org Subject: Re: [manet] RFC5444 schema-based compression V2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Thu, Jan 24, 2013 at 5:48 PM, Dearlove, Christopher (UK) wrote: > How is it proposed to put this compressed format on the wire (or over the= air more likely)? > > You can't just put it on the manet protocol/port, as that would be parsed= as 5444, which it isn't. > > Approaches I could see include (but this is not an exhaustive list; new, = better, ideas welcome). > - This is for specialised uses (e.g. as in something like 6LOWPAN). We could consider it as some kind of "linklayer compressor/decompressor" in some cases, which means the UDP packets of RFC5444 get compressed and decompressed by some device driver. ROHC (Robust Header Compression) is similar I think. > - On some other port (I doubt you'd get another protocol). > - Describing a new 5444 version 1. It's a bit of an abuse, as it's not > exactly a version, but maybe. In a certain sense it is... it contains the same "internal structure", it has just been transformed into a different representation. If there would be a protocol to query for an unknown schema, we could even have nodes learning from each other what to do with this packets as long as they are marked correctly. > I'd also want to be convinced that these schemas allow extensions > without changing the schema. For example suppose I decide to add > to either NHDP's HELLO message or OLSRv2's TC message that these > could advertise blacklisted addresses (whatever that means) using > a BLACKLIST TLV. That needs to be possible without updating the > schema to know about that TLV. (Why? TLVs in the private/experimental > space for a start.) Yes, it does. In each compressed TLV-Block, after all the bits in the bitfield that mark the presence of certain compressed TLVs there is a final bit that says "uncompressed TLVs follow". If this bit is a "1", you will process the compressed TLVs first, then read a normal 2-byte length field and start processing uncompressed TLVs. This way we have another "upgrade path" from one schema to the other one. Of course when you do so, you might also start working on a new schema for your deployment too. But I think its mandatory that there is a way to add things that are not described in the schema. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan ******************************************************************** 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. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Fri Jan 25 02:42:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A077D21F85E2 for ; Fri, 25 Jan 2013 02:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPQWX-Awsepu for ; Fri, 25 Jan 2013 02:42:04 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 20BE521F85DA for ; Fri, 25 Jan 2013 02:42:03 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TygjS-0000M2-FX; Fri, 25 Jan 2013 11:42:02 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TygjS-00088P-Cn; Fri, 25 Jan 2013 11:42:02 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 11:42:02 +0100 Message-ID: <51026179.9050908@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 11:42:01 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <51014AEB.6070402@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030407020908050406070306" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16566/Fri Jan 25 06:41:42 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d11929bbb37d0bf82123645737fe3651 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:42:04 -0000 --------------ms030407020908050406070306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/25/2013 11:13 AM, Dearlove, Christopher (UK) wrote: > The linklayer concept obviously means one would have to consider 5444 > packets, not just messages. Yes, I agree. The packet-compression level is not there because I had to = start at one point to write the idea down. I WANT a compression scheme=20 for all parts of RFC5444 (including packet level and addresses), not=20 just the TLVs of messages. > It could be argued to be a layer > violation, but then several things done in such circumstances could > be so considered. Yes, thats right. A "version 1" of packet-bb might be a better approach. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030407020908050406070306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUxMDQyMDFaMCMGCSqGSIb3DQEJBDEWBBQlUqzu07LzH0nuYp7uIAUSd+fosjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAv2cUKN3SK6yEmy16uH7xNjN5vmDnURZA2Zbek8WoX0N6 BTd41MFm3A1L7PuZw/YIaHznx2h7hlko+AXa6yI4MM7d3ImI497ZYoFpY+AVZExzCNmhK0hn rodEMT1eH4h26daWteLPVoiGIHfTviKdb2mgs0Kd28wy4/7GXDsB0v4HA3ivcTPFhNWclaUY QnCTjEd4iYpoMr5ghh59yGRFWtUDEym4TflkGP81rRZL1aUed1mZNcpZFSlum8Tc9doTpRCz CyiI2vunYedStOIiRyXnEZqTPlw9nnaOFpM31n5F8b2wwt8sd8r1UX9zxWmh9oaSZuZXyFoe SdadSx8AOgAAAAAAAA== --------------ms030407020908050406070306-- From abdussalambaryun@gmail.com Fri Jan 25 03:07:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12321F865D for ; Fri, 25 Jan 2013 03:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QE8iDBT5YYI for ; Fri, 25 Jan 2013 03:07:26 -0800 (PST) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DFF4E21F8658 for ; Fri, 25 Jan 2013 03:07:25 -0800 (PST) Received: by mail-da0-f54.google.com with SMTP id n2so125516dad.41 for ; Fri, 25 Jan 2013 03:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Kc2BqAKN/D5VpkrccDbocWsyWGEMzDRPI7nv8myDUzk=; b=SJyOJ67FAaAfyvTr8smNFGL0/2aMytaBE0RVz4H8YUCCz3AwzBcN+gehroVf7xXrzC hx9Jf21HtdSL4zIaZkztBuBQUG7+75Ihkck32BNxof4nt5syGGknbKacQEfxSdRU8uMe NgD046rVqua/CYaD7vYLHkDoUc/tuuNsr9Izdrhvtwtq8joNKoCwOpJ78Q6Rdf86UqgR Ljlc5UxDtB3oJ9JNwuEzA9L+75Fgik0gSRXgnAOz9ATzcFP6JAMQ7MF+Mv84J21fJiU1 igjgwpmZGTIioC8L27xU5PGIza3hNviikJAVztU+m3VpqPJ3Lhz1/fbJv9C8oDSeiD0c 0FaA== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr13087728pbc.140.1359112045536; Fri, 25 Jan 2013 03:07:25 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 03:07:25 -0800 (PST) In-Reply-To: <51026179.9050908@fkie.fraunhofer.de> References: <51014AEB.6070402@fkie.fraunhofer.de> <51026179.9050908@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 12:07:25 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:07:26 -0000 On 1/25/13, Henning Rogge wrote: >> It could be argued to be a layer >> violation, but then several things done in such circumstances could >> be so considered. > > Yes, thats right. > > A "version 1" of packet-bb might be a better approach. > V1 is better approach because more general than V2 for MANETs. If you make a way in Schema to have the options both include or not-include the 5444 packet, then will be better for more general MANETs, my thoughts, not sure yet :( AB From teco@inf-net.nl Fri Jan 25 03:52:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D821F842F for ; Fri, 25 Jan 2013 03:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ippdVOBfN0Hu for ; Fri, 25 Jan 2013 03:52:10 -0800 (PST) Received: from mail-we0-x230.google.com (we-in-x0230.1e100.net [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB2621F842B for ; Fri, 25 Jan 2013 03:52:09 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so138231wey.35 for ; Fri, 25 Jan 2013 03:52:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=pcvma2JcixkeHvFhjJZeENH1Vkjv9N3w7RKs7NEvOyg=; b=mUXHp+kfstYVTRAeYZ+sVS8cxMnMIaAhcXft3avqn0jsWNPHRlWfrZqx28XcHucWK5 DrnGRyZ53ku/fDshfs6Vk6a8kuXdEgq7i6IsFsYxZYyqs288aOHr+xs5QGvzBY56uwaQ D2dr1ruwAZg3yQFWgyx2emjP+2enAJqngyHi1tfitP+gLcZ5pUvUjXEnibZAltyqQvfm CUlxgCI2HTzVNOS7epbJ25pYtvAH5P5C2MJ6TwHrt1rpji3oi07wA7DzWOMWEhluh3qt eTRVvJuXIny/X5XcIbTQeBrgwTqOQepV53ZHpi3Ego/gEic8etLFSXjTMW3VEkoBf8V2 /oew== X-Received: by 10.194.84.68 with SMTP id w4mr8376387wjy.51.1359114728764; Fri, 25 Jan 2013 03:52:08 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id s10sm1420586wiw.4.2013.01.25.03.52.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 03:52:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <51023F7E.9020103@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 12:52:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnp3OYpchA1sVI70EgMItddWw8xV5Te0Wsw9FjdvAhbnBwiWJZsuLMRAubxmlLHxkr4wwCL Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:52:11 -0000 Op 25 jan. 2013, om 09:17 heeft Henning Rogge het volgende geschreven: > On 01/25/2013 08:50 AM, Teco Boot wrote: >>=20 >> Op 24 jan. 2013, om 15:53 heeft Henning Rogge het volgende >> geschreven: >>=20 >>> Maybe the schema number should be a two-byte identifier? >> It does make sense to use short fields as much as possible, that's >> the goal of compression, right? Having many schema's could bring high >> compression rates. Limitation on schema numbers brings unneeded >> restrictions. So why not put integers in variable length fields? >=20 > Not sure we would normally safe that much. >=20 > Less than one byte doesn't make much sense, unless you want to start = bitshift everything in the following data. >=20 > What we could do would be to allocate the first bit as a "7 bit/15 = bit" switch for the schema id. >=20 > If the first bit is zero, just take the first byte as the schema = number. > If the first bit is one, set it to zero and take the first TWO bytes = as the schema number. >=20 > What do you think? My thoughts are: this is done before: Using Self-Delimiting Numeric = Values in Protocols. http://tools.ietf.org/html/rfc6256 Further optimization, with values near to to 0xFF / 0xFFFF: flip the = bits. The flip indicator could be in the schema or an additional bit, = e.g. first octet, second bit leaving 6 bits for payload. Teco >=20 > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From Chris.Dearlove@baesystems.com Fri Jan 25 03:55:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF44321F87F3 for ; Fri, 25 Jan 2013 03:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD13eFXacyHl for ; Fri, 25 Jan 2013 03:55:03 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id D162621F8782 for ; Fri, 25 Jan 2013 03:55:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,537,1355097600"; d="scan'208";a="303404217" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 25 Jan 2013 11:55:01 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0PBt03g012555 for ; Fri, 25 Jan 2013 11:55:00 GMT X-IronPort-AV: E=Sophos;i="4.84,537,1355097600"; d="scan'208";a="4629137" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 25 Jan 2013 11:55:00 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Fri, 25 Jan 2013 11:55:00 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN+kKjqBkFl6yaQEqIsMfk71Dq05hYrXlwgAAJGACAAR0kQIAACPyAgAAUOKA= Date: Fri, 25 Jan 2013 11:55:00 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51026179.9050908@fkie.fraunhofer.de> In-Reply-To: <51026179.9050908@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:55:03 -0000 I have mixed views over this being version 1, but let's see where we go tec= hnically. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 25 January 2013 10:42 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] RFC5444 schema-based compression V2 On 01/25/2013 11:13 AM, Dearlove, Christopher (UK) wrote: > The linklayer concept obviously means one would have to consider 5444 > packets, not just messages. Yes, I agree. The packet-compression level is not there because I had to=20 start at one point to write the idea down. I WANT a compression scheme=20 for all parts of RFC5444 (including packet level and addresses), not=20 just the TLVs of messages. > It could be argued to be a layer > violation, but then several things done in such circumstances could > be so considered. Yes, thats right. A "version 1" of packet-bb might be a better approach. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Jan 25 04:00:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAB21F87B2 for ; Fri, 25 Jan 2013 04:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7h01bJKM+HJ for ; Fri, 25 Jan 2013 04:00:29 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4A21F87B1 for ; Fri, 25 Jan 2013 04:00:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,538,1355097600"; d="scan'208";a="303406533" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 25 Jan 2013 12:00:28 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0PC0Rpv020027 for ; Fri, 25 Jan 2013 12:00:27 GMT X-IronPort-AV: E=Sophos;i="4.84,538,1355097600"; d="scan'208";a="4630094" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 25 Jan 2013 12:00:27 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 25 Jan 2013 12:00:27 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot , Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN+kKjqBkFl6yaQEqIsMfk71Dq05hZrLkAgAAHdgCAADwXAIAAAVXg Date: Fri, 25 Jan 2013 12:00:26 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> In-Reply-To: <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:00:30 -0000 If you know that this will be two bytes maximum, then RFC 6256 is wasteful,= it has a maximum of 14 information bits rather than 15 information bits. D= o we need to consider cases where message or TLV block length is more than = 32K? (Though 5444 supports these in theory.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: 25 January 2013 11:52 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] RFC5444 schema-based compression V2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Op 25 jan. 2013, om 09:17 heeft Henning Rogge het volgende geschreven: > On 01/25/2013 08:50 AM, Teco Boot wrote: >>=20 >> Op 24 jan. 2013, om 15:53 heeft Henning Rogge het volgende >> geschreven: >>=20 >>> Maybe the schema number should be a two-byte identifier? >> It does make sense to use short fields as much as possible, that's >> the goal of compression, right? Having many schema's could bring high >> compression rates. Limitation on schema numbers brings unneeded >> restrictions. So why not put integers in variable length fields? >=20 > Not sure we would normally safe that much. >=20 > Less than one byte doesn't make much sense, unless you want to start bits= hift everything in the following data. >=20 > What we could do would be to allocate the first bit as a "7 bit/15 bit" s= witch for the schema id. >=20 > If the first bit is zero, just take the first byte as the schema number. > If the first bit is one, set it to zero and take the first TWO bytes as t= he schema number. >=20 > What do you think? My thoughts are: this is done before: Using Self-Delimiting Numeric Values = in Protocols. http://tools.ietf.org/html/rfc6256 Further optimization, with values near to to 0xFF / 0xFFFF: flip the bits. = The flip indicator could be in the schema or an additional bit, e.g. first = octet, second bit leaving 6 bits for payload. Teco >=20 > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 _______________________________________________ manet mailing list manet@ietf.org https://www.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. ******************************************************************** From teco@inf-net.nl Fri Jan 25 04:22:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57C21F84F5 for ; Fri, 25 Jan 2013 04:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDIUCfwgHjUu for ; Fri, 25 Jan 2013 04:22:55 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 43E8321F84D5 for ; Fri, 25 Jan 2013 04:22:54 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so189442wgb.13 for ; Fri, 25 Jan 2013 04:22:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FT/tQBLRXhtoX26WVz/ah5laxFAntefyMv8o1p2Ce2g=; b=p1E6GgpcQIsY/Os6/JlBN5N8XJLNqvbJYrtmMs8OxpfZU3g15DoO17tz/IrGmy40LL uSaEtpeI4knPM6eGJycpvXkpUL7fWXhUm0QHDSGnt8TBbd2uACud1VkrW2GWfKmIW7v6 OGmZf1lnUkSG35F0VR0YYbwjlZ+zyT32q3/M+XjNyNw3jMdq3HkR18H6+KzrniXVjbjH LAwlbDq8c/7FOt4nUfDIV8JM4dA9ppZE7g3wFzw6slPYBudJ9Db4HHyuMc3MMID9rlT7 8grZpVTBHy2yJn7jf0dJ763+dCGJY1rO18e18eXui+C4OrcofMAPQTC06sWFZayByEyM 6gJA== X-Received: by 10.180.99.227 with SMTP id et3mr8363737wib.6.1359116573058; Fri, 25 Jan 2013 04:22:53 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id g2sm1557693wiy.0.2013.01.25.04.22.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 04:22:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Fri, 25 Jan 2013 13:22:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnF5KP3PbpwaywN2G8/CQbx7dWzIOXLEhebZKORz1hmCVEMKSVSyvOWKXRV1s/NPXOiq0bo Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:22:56 -0000 There is the SDNV-8/-16 method. Maybe leave this open and use the schema = to select. Teco Op 25 jan. 2013, om 13:00 heeft Dearlove, Christopher (UK) het volgende = geschreven: > If you know that this will be two bytes maximum, then RFC 6256 is = wasteful, it has a maximum of 14 information bits rather than 15 = information bits. Do we need to consider cases where message or TLV = block length is more than 32K? (Though 5444 supports these in theory.) >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Teco Boot > Sent: 25 January 2013 11:52 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] RFC5444 schema-based compression V2 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Op 25 jan. 2013, om 09:17 heeft Henning Rogge het volgende geschreven: >=20 >> On 01/25/2013 08:50 AM, Teco Boot wrote: >>>=20 >>> Op 24 jan. 2013, om 15:53 heeft Henning Rogge het volgende >>> geschreven: >>>=20 >>>> Maybe the schema number should be a two-byte identifier? >>> It does make sense to use short fields as much as possible, that's >>> the goal of compression, right? Having many schema's could bring = high >>> compression rates. Limitation on schema numbers brings unneeded >>> restrictions. So why not put integers in variable length fields? >>=20 >> Not sure we would normally safe that much. >>=20 >> Less than one byte doesn't make much sense, unless you want to start = bitshift everything in the following data. >>=20 >> What we could do would be to allocate the first bit as a "7 bit/15 = bit" switch for the schema id. >>=20 >> If the first bit is zero, just take the first byte as the schema = number. >> If the first bit is one, set it to zero and take the first TWO bytes = as the schema number. >>=20 >> What do you think? >=20 > My thoughts are: this is done before: Using Self-Delimiting Numeric = Values in Protocols. > http://tools.ietf.org/html/rfc6256 >=20 > Further optimization, with values near to to 0xFF / 0xFFFF: flip the = bits. The flip indicator could be in the schema or an additional bit, = e.g. first octet, second bit leaving 6 bits for payload. >=20 > Teco >=20 >>=20 >> Henning Rogge >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.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 From henning.rogge@fkie.fraunhofer.de Fri Jan 25 07:00:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04F621F8864 for ; Fri, 25 Jan 2013 07:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmAutFIT6fiW for ; Fri, 25 Jan 2013 07:00:48 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1784E21F8863 for ; Fri, 25 Jan 2013 07:00:47 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tyklo-0001xI-PZ; Fri, 25 Jan 2013 16:00:44 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tyklo-0006fB-Mr; Fri, 25 Jan 2013 16:00:44 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 16:00:44 +0100 Message-ID: <51029E17.7070501@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 16:00:39 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teco Boot References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> In-Reply-To: <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010806020705000008080001" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16567/Fri Jan 25 12:42:34 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ff5b53f4d81aecd7a6b2d230e03a1f9e Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:00:49 -0000 --------------ms010806020705000008080001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If we are only need to encode 16 bits, we could do it this way: 1) if you encode 0-127, just use a single byte value. 2) if you encode 128 - 32511 (0x7eff), add 0x8000 and and use a two byte = value. 3) if you encode 32512 - 65535, first write 0xff and then write the full = two bytes. Henning Rogge On 01/25/2013 01:22 PM, Teco Boot wrote: > There is the SDNV-8/-16 method. Maybe leave this open and use the schem= a to select. > > Teco > > Op 25 jan. 2013, om 13:00 heeft Dearlove, Christopher (UK) het volgende= geschreven: > >> If you know that this will be two bytes maximum, then RFC 6256 is wast= eful, it has a maximum of 14 information bits rather than 15 information = bits. Do we need to consider cases where message or TLV block length is m= ore than 32K? (Though 5444 supports these in theory.) --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010806020705000008080001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUxNTAwNDJaMCMGCSqGSIb3DQEJBDEWBBQc+kdyW75b2uspIbYHcI6LDl0bzTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAtjk52PYf7P1199bSeI0WbIvLk5Ybl7J5AI9bouL6qFxb dv6cklO0X51pYK/bYVLjzWGqYcQY3Ewya+/+nePwyp7OrneenVQTXcfIXQ6HrWBVOM9sJjMs Mf+Bi3wJJGTnD6/1Nkj99PoeKKy5DwSYsrXR1xpGHFhsS0VSCW3v83eD0903xjLIYDFm5b0r X6/KJ+f4QYk9Hm9DkKc6th7mss3qqy8X17+kSnfdZl0+yjmOUp4V5aBVGc05zjJggsLdo454 fGmy4OYt3g27sPrMq1ygLJBgQhfl3BO2Dt46A4x1hKke+XXLlJD8aUtkqqeiPJisXZMokOgv t2MnZPEANQAAAAAAAA== --------------ms010806020705000008080001-- From henning.rogge@fkie.fraunhofer.de Fri Jan 25 07:21:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506B021F8438 for ; Fri, 25 Jan 2013 07:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTirjXNY60zm for ; Fri, 25 Jan 2013 07:21:01 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4BA21F841F for ; Fri, 25 Jan 2013 07:20:55 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tyl5I-0000Jy-V7; Fri, 25 Jan 2013 16:20:52 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tyl5I-0007Dl-SO; Fri, 25 Jan 2013 16:20:52 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 16:20:52 +0100 Message-ID: <5102A2D3.9050303@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 16:20:51 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teco Boot References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> In-Reply-To: <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070903050300070808040308" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16567/Fri Jan 25 12:42:34 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 44205366898805df1de72924aa95b600 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:21:02 -0000 --------------ms070903050300070808040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/25/2013 01:22 PM, Teco Boot wrote: > There is the SDNV-8/-16 method. Maybe leave this open and use the schem= a to select. After looking through RFC6256, I think we could easily use this one. The = one-byte more overhead for TLV-blocks longer than 16K Byte is not really = that relevant. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070903050300070808040308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUxNTIwNTFaMCMGCSqGSIb3DQEJBDEWBBQzc5vCn4a6q2kQJSZW6h0On6sO9zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAGZNm0WxPW7OaqkEpVsj5bLEM7AStvHQMp4TAoqWKtaMV 25TZfP0LWOn+nMhmSjs3WRfNJR8wySkEg5pNdln3a2YhjHT4fLHjYcK1GXdyN4gV2McCC1rk N++xfKEb9niiUxhkTEOhtkmND9ODFKCBZZ5+XSx/90ZAuzs8FZPg9BCL0KjwhHRpurZHenOr xW31umNGcnINf4TdZ/y+rQGC2eknq/Ip/UKv85/2tB7zbC8+ODSabDl1TLO75GQwQIQD4d3y IzDo73HZOafdYk8/d2XAcWyKgPD6WY9jQcacQvM9DsFSCZjIY7DymPSnZxFU96IkmLR/krDf s4roYPeqWQAAAAAAAA== --------------ms070903050300070808040308-- From teco@inf-net.nl Fri Jan 25 07:27:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57321F8896 for ; Fri, 25 Jan 2013 07:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMh0sPojXWDG for ; Fri, 25 Jan 2013 07:27:29 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E905B21F8893 for ; Fri, 25 Jan 2013 07:27:28 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so1140579wgh.1 for ; Fri, 25 Jan 2013 07:27:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9D0ilfOzKBAaN65XHdJrbjHqHAt52hdcRZf3ceXG0cs=; b=H5JipAyIWE9+tuq5XBaZQLzH66b9d6WVHhW/ZohqK6lXAEjVXnxPwaLZVwGt09B+7j ENQ5aCNl/nbk5tCZq1LgBOzQCWOPN/1Zut5vYMsJfD+RgFHIvItXhqsBdWDGepy2Jo4H 7tY3ZJKZTkfuI+lXFQrxxJYOYF8tBqTv3p3uLBlMOgy5syPq7BcHx7F0avP1FxLsK9+v oOEyomq0+MFOubQECxCHN32xK4Vc4tjSZUAQlajmZb1TWEudj4bo/gwON8/SHMy9S9HU hTEOz2E+JZiDVAYRo93sfp/2w8TQ1td0JtqAyTNdMQg+aWILks/Ur81C3PTC1OWemfMc mN8g== X-Received: by 10.180.88.134 with SMTP id bg6mr9251314wib.26.1359127647417; Fri, 25 Jan 2013 07:27:27 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id u6sm2298997wif.2.2013.01.25.07.27.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 07:27:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <5102A2D3.9050303@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 16:27:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkpmzKuafY/o92CjoeIyt3SNUMasX2fefMcwraCMrnH/tcPYGN/LB4+dAWHN8eRXkmxC42q Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:27:30 -0000 I'm fine as long as it is unlikely to face higher overhead encoding for = values that are frequently used. My worries are for the 0xFFxx range. Teco Op 25 jan. 2013, om 16:20 heeft Henning Rogge het volgende geschreven: > On 01/25/2013 01:22 PM, Teco Boot wrote: >> There is the SDNV-8/-16 method. Maybe leave this open and use the = schema to select. >=20 > After looking through RFC6256, I think we could easily use this one. = The one-byte more overhead for TLV-blocks longer than 16K Byte is not = really that relevant. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From henning.rogge@fkie.fraunhofer.de Fri Jan 25 07:29:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F4821F88B9 for ; Fri, 25 Jan 2013 07:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSGfSnJ+xsPG for ; Fri, 25 Jan 2013 07:29:17 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id AD00021F8896 for ; Fri, 25 Jan 2013 07:29:16 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TylDQ-0002hI-2Y; Fri, 25 Jan 2013 16:29:16 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TylDP-0007N9-W5; Fri, 25 Jan 2013 16:29:16 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 25 Jan 2013 16:29:15 +0100 Message-ID: <5102A4CA.4080206@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 16:29:14 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teco Boot References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> In-Reply-To: <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010706090709050606070409" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16567/Fri Jan 25 12:42:34 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a22a8819f20226a2167e46b22584aa1b Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:29:17 -0000 --------------ms010706090709050606070409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/25/2013 04:27 PM, Teco Boot wrote: > I'm fine as long as it is unlikely to face higher overhead encoding > for values that are frequently used. My worries are for the 0xFFxx > range. I do not think compressed message length or Schema numbers larger than 16000 will be common for RFC5444 packets. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010706090709050606070409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjUxNTI5MTRaMCMGCSqGSIb3DQEJBDEWBBS26RyZmPQmY8j6OsS3dvxnLsN1+TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEARIfSuheLD3TMqx/gpBW0JDHC0zh/REKZHeBhmT7A9ltj zVgulHlME+sP4xsOcYUGB1YzZsIlWKY0QdMwU1IGidpqjfwZLlb2kViWzyNBdHEyM3GhbVp+ gr9jTNHhF/6Vaj8V3+vCx+LZM4zM7GXtstem1vPxyz38L4/NvbiNA7O8gDtX7cLFdsawsGcN 1vtVKwt328MyHAcM1py3z4SekEgAtWXLBwZlnA8KzB6izuV9A+zOBN8S3QFgUFeuIVSby0LK HOle6UMG6oFUNQwr0aPuNCnkUjst5v/JRwAZarEmhKRHxKRiytsMpjaW2pp5iZol2tbGR77i 8aJMh2HBUQAAAAAAAA== --------------ms010706090709050606070409-- From abdussalambaryun@gmail.com Fri Jan 25 07:49:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED921F8887 for ; Fri, 25 Jan 2013 07:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhsJJxI6i0ki for ; Fri, 25 Jan 2013 07:49:55 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id B187D21F8873 for ; Fri, 25 Jan 2013 07:49:55 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id fb10so328652pad.2 for ; Fri, 25 Jan 2013 07:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W/L+T2rWWLQI4gXB92tKhbarfkm8QNP2AxIM49OfO6Q=; b=FU2UqPYzUHSUccRnHNKEgUvI7IzPI0nEGV0h+QRQAf3BKxVqv9gWk6Frc25scvQebI y8CfIlc8gUot3vfm+ymbMQGzK8E31DEyLlLM2vfvWNWEgGFZLZ4WVKt3PpCiok0keCv6 T2C9CWjv4RhzSwXbNnhPiuumhZIp3j5CWvGDew2anFdB2vq88/L6NYAgbQtjI5cE+OMo 5THibNPoQAeW+xb6m1bZDkWLg1gakva2FSng5GH4KTkP/2TPsJ0lDL0+ulumAc6VnDbC HeMzLu+H1WFVQ9OQ6gCPnRAKkeXX2odBKzigviUd6iolBTcqAAmvRPWCKtXFVDKLLm77 HxMw== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr15317260pbc.20.1359128995548; Fri, 25 Jan 2013 07:49:55 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 07:49:55 -0800 (PST) In-Reply-To: <51029E17.7070501@fkie.fraunhofer.de> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <51029E17.7070501@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 15:49:55 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b33d066fbcd4204d41ee0af Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:49:57 -0000 --047d7b33d066fbcd4204d41ee0af Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 25, 2013 at 3:00 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > If we are only need to encode 16 bits, we could do it this way: > > 1) if you encode 0-127, just use a single byte value. > 2) if you encode 128 - 32511 (0x7eff), add 0x8000 and and use a two byte > value. > 3) if you encode 32512 - 65535, first write 0xff and then write the full > two bytes. > > > For the third one do you mean it will be three bytes: 0xff xx xx = 24 bits not as the condition, or do you mean encode 32512 - 32767, first write 0xff and complete the two byte = 16 bits Not sure how do you distinguish between values 32767 and 65535 and more others? Please help because I want to understand this, AB --047d7b33d066fbcd4204d41ee0af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 25, 2013 at 3:00 PM, Henning Rogge <= span dir=3D"ltr"><henning.rogge@fkie.fraunhofer.de> wrote:
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">

If we are only need to encode 16 bits, we could do it this way:

1) if you encode 0-127, just use a single byte value.
2) if you encode 128 - 32511 (0x7eff), add 0x8000 and and use a two byte va= lue.
3) if you encode 32512 - 65535, first write 0xff and then write the full tw= o bytes.

=A0

For the third one do you mean it wi= ll be three bytes: 0xff=A0 xx=A0 xx=A0=A0=A0 =3D 24 bits=A0 not as the cond= ition,
or do you mean encode 32512 - 32767, first write 0xff and complete the= two byte =3D 16 bits
=A0
Not sure how do you distingui= sh between values 32767 and 65535 and more others?
=A0
= Please help because I want to understand this,
=A0
AB

--047d7b33d066fbcd4204d41ee0af-- From abdussalambaryun@gmail.com Fri Jan 25 07:53:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2943A21F8880 for ; Fri, 25 Jan 2013 07:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoNus+auSoCR for ; Fri, 25 Jan 2013 07:53:46 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 917FE21F87F3 for ; Fri, 25 Jan 2013 07:53:46 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id x6so227454dac.12 for ; Fri, 25 Jan 2013 07:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mOFk9xL7rXRpqZ4DcCvR3C9hqO9WM9d9/vJl68+4frg=; b=usVLFJquckAZdn5nuoB4wjBHzdQPBmrvPXPJWovTUmCZlGO1MetEHKQrP9NUJrRUxG CYLPJTDt47546DfCTD0wkF3+S3kPrYbMuSBetmuFO0FptZUMmn+RTCHcDK3HPgqA0e8E N5cRWE1qQkj9ep3r/+cyYKgMEl55O+9r1oQFM2Sa9kk69TbziX19sBMsdrgqHJ5yj7ih oNHHvxnyyfa4qTmKkW9xWdT156bqXT0stq4Og0SUpVJNdv1OyFevECiEtaj0hhFO+zvF 0FNDWIxoZ6Kvx8zgiRVgT0rZsWrfAIxIYJ+d5luKsP5yt9RXcJ+yWgqVLONoVnobj/AC 4Cvg== MIME-Version: 1.0 X-Received: by 10.68.136.73 with SMTP id py9mr15343740pbb.43.1359129226319; Fri, 25 Jan 2013 07:53:46 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 07:53:46 -0800 (PST) In-Reply-To: <5102A4CA.4080206@fkie.fraunhofer.de> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <5102A4CA.4080206@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 15:53:46 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b15b11bbd162904d41eee22 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:53:47 -0000 --047d7b15b11bbd162904d41eee22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 16000 is large for the cases, I agree too, AB On Fri, Jan 25, 2013 at 3:29 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 01/25/2013 04:27 PM, Teco Boot wrote: > >> I'm fine as long as it is unlikely to face higher overhead encoding >> for values that are frequently used. My worries are for the 0xFFxx >> range. >> > > I do not think compressed message length or Schema numbers larger than > 16000 will be common for RFC5444 packets. > > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b15b11bbd162904d41eee22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
16000 is=A0large for the cases, I agree too,
=A0
A= B

On Fri, Jan 25, 2013 at 3:29 PM, = Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 01/25/2013 04:27 PM, Teco Boot wrote:=
I'm fine as long as it is unlikely to face higher overhead encoding
for values that are frequently used. My worries are for the 0xFFxx
range.

I do not think compressed message length or Schema numbers larger than
16000 will be common for RFC5444 packets.


Henning Rogge


--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b15b11bbd162904d41eee22-- From teco@inf-net.nl Fri Jan 25 08:58:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6C021F856C for ; Fri, 25 Jan 2013 08:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clQgIQtIeW7Z for ; Fri, 25 Jan 2013 08:58:52 -0800 (PST) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1153021F854F for ; Fri, 25 Jan 2013 08:58:51 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so1200162wgb.2 for ; Fri, 25 Jan 2013 08:58:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OumnRkrnXgR+p0l3y2tbFAmYDF/lVu0nYHV/JswL3Ak=; b=CcG6iKnHqyxVRwy2ek94LeDNTZWcgomcihaZYJjbthUOLHdiOUIUmRekX+02Sso7n0 XV3BAsgQyzvEZ3I8Q7ysNSisoKbKohfWfKQxA2s8Eu5jAYRfJ5kHg/zvrUqZG/vrlpgz +kSUONFz4061mKEaXZ4LFhvvRCRx6NOY4pfshRtb/sAmSBKEoVeyrDVfzwWgOJzmOjTP yuAX2Sx/mAiUFZjB5ZgRArX6y+1hUEe9G6T/cjfR+OpYGxluNBSHHiRYDTjk6+E1oMCb +ylaFUXcEwbHwUGwkNeR7EUwyZf8dQSMTENnabata4lj0HzGZ06WHPUWTbKVsJezi3aX ILdQ== X-Received: by 10.194.94.37 with SMTP id cz5mr1290854wjb.49.1359133130588; Fri, 25 Jan 2013 08:58:50 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id s16sm8139538wii.0.2013.01.25.08.58.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 08:58:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <5102A4CA.4080206@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 17:58:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <5102A4CA.4080206@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnNBYzS/QTbJC1O/7yKXzriSxPTyMCH8Sf0gu6I97LxcZczZIdSCHGL+kO/3qVRHddQFYXh Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:58:53 -0000 Op 25 jan. 2013, om 16:29 heeft Henning Rogge het volgende geschreven: > On 01/25/2013 04:27 PM, Teco Boot wrote: >> I'm fine as long as it is unlikely to face higher overhead encoding >> for values that are frequently used. My worries are for the 0xFFxx >> range. >=20 > I do not think compressed message length or Schema numbers larger than > 16000 will be common for RFC5444 packets. I was thinking on tlv-fulltype, with experimental TLV types. OK, maybe not optimize for experiments. And stick to RFC6256. Teco >=20 > Henning Rogge >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From abdussalambaryun@gmail.com Fri Jan 25 09:07:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FAB21F8884 for ; Fri, 25 Jan 2013 09:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlCR2jvl1wLS for ; Fri, 25 Jan 2013 09:07:28 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3CD21F8878 for ; Fri, 25 Jan 2013 09:07:28 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so368718pad.31 for ; Fri, 25 Jan 2013 09:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xzW/5kLgAtC3AjXE5ZKpJphhwtdN+OV97hxL90Yzwvc=; b=0HEYE8HlGdz1ibVhwHV0fGLxPNt7zEakCzREF9FSrInNIBozPvNPgDORcj6K9bvkpI Tsu6bHEYEu4XQypmnvmqmRZQRTywm8IIuOTiR2lSBDtz5e2H+UKsqWx+yCVtGK07TlOn CqvPhblD6osojFhF/45lJBgppcPWLnv/DNbUZ9mYBEX1hI7qyN5VJOLSPtt4owcP70WR H43WYfaAj1sbRJSs53lCoG90eZRG0nRtf+alSKfd/w3sE4yCdvyC9VpuBNM02edTFWoX bFqd8HjiZg3DW57AD9ONtDGRKYyWwFC0hCIUKbNCr0nuicUs8SR0JVqarJHlEAW/r+FI 32eQ== MIME-Version: 1.0 X-Received: by 10.69.0.40 with SMTP id av8mr15818184pbd.117.1359133648105; Fri, 25 Jan 2013 09:07:28 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 09:07:27 -0800 (PST) In-Reply-To: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <5102A4CA.4080206@fkie.fraunhofer.de> Date: Fri, 25 Jan 2013 17:07:27 +0000 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=047d7b2e13014c326704d41ff6d5 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:07:29 -0000 --047d7b2e13014c326704d41ff6d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree to stick with RFC6256, AB On Fri, Jan 25, 2013 at 4:58 PM, Teco Boot wrote: > > Op 25 jan. 2013, om 16:29 heeft Henning Rogge het volgende geschreven: > > > On 01/25/2013 04:27 PM, Teco Boot wrote: > >> I'm fine as long as it is unlikely to face higher overhead encoding > >> for values that are frequently used. My worries are for the 0xFFxx > >> range. > > > > I do not think compressed message length or Schema numbers larger than > > 16000 will be common for RFC5444 packets. > > I was thinking on tlv-fulltype, with experimental TLV types. > OK, maybe not optimize for experiments. And stick to RFC6256. > > Teco > > > > > Henning Rogge > > > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b2e13014c326704d41ff6d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree to stick with RFC6256,
=A0
AB

On Fri, Jan 25, 2013 at 4:58 PM, Teco Boot <teco= @inf-net.nl> wrote:

Op 25 jan. 2013, om 16:29 heeft Henning Rogge het volgende geschreven:

> On 01/25/2013 04:27 PM, Teco Boot wrote:
>> I'm fine as long as it is unlikely to face higher overhead enc= oding
>> for values that are frequently used. My worries are for the 0xFFxx=
>> range.
>
> I do not think compressed message length or Schema numbers larger than=
> 16000 will be common for RFC5444 packets.

I was thinking on tlv-fulltype, with experimental TLV types.
OK, maybe not optimize for experiments. And stick to RFC6256.

Teco

>
> Henning Rogge
>
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
> mailto:henning.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>

_____________________________= __________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b2e13014c326704d41ff6d5-- From Chris.Dearlove@baesystems.com Fri Jan 25 10:07:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6221F88B6 for ; Fri, 25 Jan 2013 10:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftJ45qGSjqoX for ; Fri, 25 Jan 2013 10:07:46 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id C62AA21F88B1 for ; Fri, 25 Jan 2013 10:07:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="257762508" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Jan 2013 18:07:45 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r0PI7isH013691 for ; Fri, 25 Jan 2013 18:07:44 GMT X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="4450633" Received: from glkxh0006v.greenlnk.net ([10.110.2.32]) by baemasodc005.greenlnk.net with ESMTP; 25 Jan 2013 18:07:44 +0000 Received: from GLKXM0008V.GREENLNK.net ([169.254.8.223]) by GLKXH0006V.GREENLNK.net ([10.110.2.32]) with mapi id 14.02.0309.002; Fri, 25 Jan 2013 18:07:44 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot , Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN+kKjqBkFl6yaQEqIsMfk71Dq05hZrLkAgAAHdgCAADwXAIAAAVXggAAHQQCAADG9gIAAAdOAgAAsZHA= Date: Fri, 25 Jan 2013 18:07:44 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> In-Reply-To: <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.19.152] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:07:46 -0000 If we are using this for lengths - of messages, TLV blocks etc. I sincerely= hope we never see a value as high as 0xFF00. (I don't think we are planning to use it for two byte values that aren't we= ighted low in that manner (i.e. not for sequence numbers etc.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 25 January 2013 15:27 To: Henning Rogge Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] RFC5444 schema-based compression V2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I'm fine as long as it is unlikely to face higher overhead encoding for val= ues that are frequently used. My worries are for the 0xFFxx range. Teco Op 25 jan. 2013, om 16:20 heeft Henning Rogge het volgende geschreven: > On 01/25/2013 01:22 PM, Teco Boot wrote: >> There is the SDNV-8/-16 method. Maybe leave this open and use the schema= to select. >=20 > After looking through RFC6256, I think we could easily use this one. The = one-byte more overhead for TLV-blocks longer than 16K Byte is not really th= at relevant. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=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. ******************************************************************** From hrogge@googlemail.com Fri Jan 25 11:59:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EB121F87F3 for ; Fri, 25 Jan 2013 11:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruzGa7bLfxYf for ; Fri, 25 Jan 2013 11:59:16 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9121F8AD6 for ; Fri, 25 Jan 2013 11:59:16 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so1369548lbo.0 for ; Fri, 25 Jan 2013 11:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=wVlbZcV7LtvtU5IGU5yFV/KGIBdyY/W5WK2ozJd3J8E=; b=jSnX6gkDalAAhpqwyH4gtr95nB/WKqA7QNX5FTQX4JRVBd8eU0AcQBBeO/5U/rHB3v pXgTleMw80hFdjTcDslXU+KjbVoH2UPkHgW/r9ieVCBYVahUzgZxZRVi2co2b6Z7VroG gA/p1Dq111qB9atxgZeoKvhbA0PzfiOM2o5WuQuy7/1bbFPPvUaaorh90dG9afBy/qsH 3UCz7OaaKFDUyNRzSwH7a24Eee0ZuOKFvLWW/QLLSvj6FZGcf+xjBJTmVVJV/zEk6WdZ /7sRq7gnpNLSZvgz2ynTJTE+AHM9109tYL4xnY6LGmbOK43BwRluKcpQ+Rbp463i3CGV sWBQ== X-Received: by 10.152.133.67 with SMTP id pa3mr6063661lab.44.1359143954106; Fri, 25 Jan 2013 11:59:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.226 with HTTP; Fri, 25 Jan 2013 11:58:53 -0800 (PST) In-Reply-To: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> From: Henning Rogge Date: Fri, 25 Jan 2013 20:58:53 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:59:17 -0000 On Fri, Jan 25, 2013 at 7:07 PM, Dearlove, Christopher (UK) wrote: > If we are using this for lengths - of messages, TLV blocks etc. I sincere= ly hope we never see a value as high as 0xFF00. For length and maybe for the Schema-ID itself. > (I don't think we are planning to use it for two byte values that aren't = weighted low in that manner (i.e. not for sequence numbers etc.) Yes, that would be stupid to do. But I am currently thinking about a few additions to help with address compression. Henning Rogge > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 25 January 2013 15:27 > To: Henning Rogge > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] RFC5444 schema-based compression V2 > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > I'm fine as long as it is unlikely to face higher overhead encoding for v= alues that are frequently used. My worries are for the 0xFFxx range. > > Teco > > Op 25 jan. 2013, om 16:20 heeft Henning Rogge het volgende geschreven: > >> On 01/25/2013 01:22 PM, Teco Boot wrote: >>> There is the SDNV-8/-16 method. Maybe leave this open and use the schem= a to select. >> >> After looking through RFC6256, I think we could easily use this one. The= one-byte more overhead for TLV-blocks longer than 16K Byte is not really t= hat relevant. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> > > > > ******************************************************************** > 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://www.ietf.org/mailman/listinfo/manet --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From henning.rogge@fkie.fraunhofer.de Mon Jan 28 02:37:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6056521F84E6 for ; Mon, 28 Jan 2013 02:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSuEFGUaT621 for ; Mon, 28 Jan 2013 02:37:52 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id DEBAB21F84DA for ; Mon, 28 Jan 2013 02:37:50 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tzm60-0000w2-9J for manet@ietf.org; Mon, 28 Jan 2013 11:37:48 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tzm60-0004tU-6d for manet@ietf.org; Mon, 28 Jan 2013 11:37:48 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 28 Jan 2013 11:37:47 +0100 Message-ID: <510654FA.5060403@fkie.fraunhofer.de> Date: Mon, 28 Jan 2013 11:37:46 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020702040006030900020005" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16578/Sun Jan 27 17:03:40 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e8c9128e393e36db5d4db300a33c163c Subject: [manet] RFC5444 schema-based compression V3 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:37:53 -0000 --------------ms020702040006030900020005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I made ome small revisions all over the place in the document. I think its getting to the point to start an I-D. Just the packet-level=20 TLV-block compression and some ideas for address compression are still=20 missing. And we have to decide how to transport the compressed data over the netwo= rk! Henning Rogge ----------------------- RFC5444 Schema Compression V3 =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=3D=3D=3D Changes since V2: - explicit "any" placeholder in schema - usage of RFC6256 - quantity of address-tlvs "per address" - added missing message header flag octet in uncompressed example - more explanation of example compression - layout cleanup Changes since V1: - restructured text to make it easier to read - added compression for address-TLVs - simplified Schema description (no more differentiation between mandatory and optional TLVs) - added explanation for TLVs schema fields Compression idea ---------------- Describe the typical content of a RFC5444 message in your deployment=20 with a Schema. Remove everything from the RFC5444 message that can be constructed from=20 Schema. Use bitfields to describe how many TLVs of each kind are present = in a TLV-block and their data. Use RFC6256 to encode compressable numbers larger than 255. Schema content -------------- Schema field values can a list of possible values (the list can contain=20 a single value) or an interval of numbers. Schema fields can be empty=20 when the field is not restricted by the Schema in any ways and has=20 always to be fully transmitted over the network. Fields for Message Header: - each of the fields of the Message Headers schema describes one of the=20 possible fields described in RFC5444 chapter 5.2 Fields for TLVs: - "quantity" limits the number of times a TLV can be present in a=20 TLV-block. The VALIDITY_TIME TLV is mandatory for all NHDP messages and=20 can only be present once, so its quantity is "1". The INTERVAL_TIME TLV=20 is optional for NHDP messages, but must not be there more than once, so=20 its quantity is "0-1". Quantity for address TLVs is PER ADDRESS! - "extension type" sets the extension type of the TLV if known. - "value length" restricts the length of the TLVs value in octets (to a=20 range or a fixed length). - "value" restricts the value itself of the TLV. Example schema -------------- Schema Number: 42 Message Header: * Type: 0 * MHasOrig: 0 * MHasHopLimit: 1 * MHasHopCount: 0 * MHasSeqnum: 1 * Address Length: 4 * Originator Address: * * Hop Limit: 1 * Hop Count: * * Sequence Number: * Message TLVs: * TLV type 0: (INTERVAL_TIME) +-- quantity: 0-1 +-- extension type: 0 +-- value length: 1 +-- value: * | * TLV type 1 (VALIDITY_TIME) +-- quantity: 1 +-- extension type: 0 +-- value length: 1 +-- value: * Addresses Block TLVs: * TLV type 2 (LOCAL_IF) +-- quantity: 0-1 +-- extension type: 0 +-- value length: 1 +-- value: 0-1 | * TLV type 3 (LINK_STATUS) +-- quantity: 0-1 +-- extension type: 0 +-- value length: 1 +-- value: 0-2 | + TLV type 4 (OTHER_NEIGHBOR) +-- quantity: 0-1 +-- extension type: 0 +-- value length: 1 +-- value: 0-1 Example message for compression ------------------------------- The message to be compressed in this example is a NHDP message: - 4-byte addresses, - hoplimit 1, - sequence number 0x1234 - an INTERVAL_TIME Message-TLV with value 0x02 - a VALDIITY_TIME Message-TLV with value 0x20 - an address block with the IP's 10.0.0.1, 10.0.0.2 and 10.0.0.3 - 3-byte head (10.0.0), no prefixes - one LOCAL_IF TLV for index 0 and value 0x00 - one LINK_STATUS_TLV for indices 1-2 and the values 0x01/0x02 - one OTHER_NEIGHBOR TLV for indices 1-2 and the values 0x01/0x00 Example compression ------------------- # The message always starts with the schema number (compressed with=20 RFC6256). 42 # Add compressed msg-size to message (also compressed with RFC6256). 17 # Skip the msg-flags AND msg-addr-length field if specified in the=20 schema, otherwise add them to the message. (none in this example) # Add all optional message header fields (Originator, Hoplimit,=20 Hopcount, Sequence Number) that are marked in the flags and are not=20 already defined in the schema. 12 34 (sequence number value) # Add a bitfield with as many bits for each TLV as needed to encode the=20 quantity of it (no bit necessary for one fixed quantity, one bit for=20 0-1, ...). Append another bit that encodes if 'other TLVs' will follow=20 the compressed ones. Append zeros to padd to a full octet. # If the quantity of a TLV is unrestricted, use RFC6256 to encode the=20 quantity. # The order of the TLVs is the same as defined in the schema. # In this example INTERVAL_TIME can be present 0-1 times and=20 VALIDITY_TIME is always present once. # binary: (1*INTERVAL_TIME, no "other TLVs") # (1*VALDIITY_TIME is implicitly defined by the schema) 1 0 # in bytes: 80 # Add all present TLVs to the compressed message. Leave out all fields=20 that can be reconstructed from the Schema. Shorten each TLVs remaining=20 fields (except tlv-flags) into bitfield as long as the possible=20 combinations need. Only compress value if can be expressed in less than=20 8 bits (padd with zero-bits before the value if not). # value of INTERVAL-TIME TLV 02 # value of VALIDITY-TIME TLV 20 # If there are other TLVs (not described in the schema), add the number=20 of bytes needed to describe them (RFC6256 encoded) and the TLVs itself=20 (uncompressed). (none in this example) # Add the uncompressed address-block to the message. 03 80 03 10 00 00 01 02 03 # Add a bitfield with as many bits for each TLV as needed to encode the=20 quantity of it (no bit necessary for one fixed quantity, one bit for=20 0-1, ...). Append another bit that encodes if 'other TLVs' will follow=20 the compressed ones. Add zeros to padd to a full octet. # The number of addresses multiplied by the quantity defined in the=20 schema determines the possible quantities of address TLVs. # If the quantity of a TLV is unrestricted, use RFC6256 to encode the=20 quantity. # The order of the TLVs is the same as defined in the schema. # In this example all TLVs can be present 0-3 times, which means two=20 bits are needed to encode the quantity of each compressed address TLV # binary: (1*LOCAL_IF, 1*LINK_STATUS, 1*OTHER_NEIGHBOR, no other TLVs) 01 01 01 0 # in bytes: 54 # Add all present TLVs to the compressed message. Leave out all fields=20 that can be reconstructed from the Schema. Shorten each TLVs remaining=20 fields (except tlv-flags) into bitfield as long as the possible=20 combinations need. Only compress value if can be expressed in less than=20 8 bits (padd with zero-bits before the value if not). # binary: LOCAL_IF flags, index-start and value 01010000 00 0 # binary: LINK_STATUS flags, index-start, index-end and two values 00110100 01 10 01 10 # binary: OTHER_NEIGHBOR flags, index-start, index-end and two values 00110100 01 10 1 0 # in bytes: 50 00 34 66 34 68 # If there are other TLVs (not described in the schema), add the number=20 of bytes needed to describe them (RFC6256 encoded) and the TLVs itself=20 (uncompressed). (none in this example) Result ------ The complete message has been reduced from 00 53 00 30 53 01 12 34 (message header) 00 08 (message-tlv block length) 00 10 01 02 (INTERVAL-TIME 0x01) 01 10 01 20 (VALIDITY-TIME 0x10) 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1,.2 and .3, no prefixes)= 00 13 (address-tlv block length) 02 50 01 01 00 (LOCAL_IF index=3D1 0x00) 03 34 02 03 01 01 02 (LINK_STATUS index=3D2-3 0x01/0x02) 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=3D2-3 0x01/0x00) (a total of 48 bytes) to 42 17 12 34 (message header) 80 02 20 (message tlvs) 03 80 03 10 00 00 01 02 03 (address block) 54 50 00 34 66 34 68 (address tlvs) (a total of 23 bytes) Comments -------- A packet-level schema entry should be added to this concept. I think there could be some more compression if the Schema includes a=20 "known prefix" for all addresses (or maybe a list of them?). This would=20 help to compress both the originator address and the prefix fields in=20 address blocks. In theory there are a few wasted bits here and there, but I decided NOT=20 to do any bit-shifting on data which is larger than 1 byte. A great addition to this idea would be a protocol for requesting unknown = schema from your neighbor. And a program that scans a RFC5444 stream and = suggests a schema based on the watched messages. --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020702040006030900020005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjgxMDM3NDZaMCMGCSqGSIb3DQEJBDEWBBTEi4/itL15Dwgz6Pyj04fSFuNZ0DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAOFILOHXcEPnShmkOiDMASYlVHe74c4aonkIGN7MW7Ruc Yhdep9T1RPmJ3Vqw7CdbdXuufKS/uMTGHT/aSDY523NNj2Yl0dR1qh/RpHLeBBSXOryeiNSz bSM/Xf4oqbRI51xNdVVJwkzLXsEbJDf6RQ+t7Ah9JY9njpSxtqieD4Wavakq3+ssoT0egmIh ini5OjmBRT1bjIbwApyCku7Pte8VEdOqVjIcP/xQwRMpgY+d70K6YNGuMYEETiA3uuPaqMld aC+WTAiDW/JTq3E9KTzg9RgYi+yOnMWJzC/eKnVB0spCPWlmzJ2dazNVZgoHM5pC8+ngxbwH h46xX//PNgAAAAAAAA== --------------ms020702040006030900020005-- From abdussalambaryun@gmail.com Mon Jan 28 02:49:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25821F87A4 for ; Mon, 28 Jan 2013 02:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WvsEB38U0ni for ; Mon, 28 Jan 2013 02:49:16 -0800 (PST) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 68DAA21F8447 for ; Mon, 28 Jan 2013 02:49:16 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id ro8so529920pbb.23 for ; Mon, 28 Jan 2013 02:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UhW/QpYZB6HOBYJJvxl6Gjqg21REsQCMya7dje7PVR8=; b=OgVxDesmlMuTb9SlpYgYP+2zy5B6SRtVSBVYVkGkALT5/oynjqA/YHESEkKrL9QH0S QsFw4nu2XL7BL2A1BJbWc3v+9Cy1UhRa2x200xMWl3ev9mQLGb7U7MZkONyhagtP/1hQ sVfRELHx0YRWyPdCbdY+ywD+bA/KYkX6YeHWIjXn1GoCFvZDyU14cTN40L0xLoGfRO0K NaO/uD5hcX5EfBxuPoWObZsf5GknYPDNXa6gH9K4+lDhY2SJSXG6eY+CnoWktd+4p+nN Vifhl8zbK+ycERA0ixgOY5TeKjxhIiDl91+v1uo7CXWUfDflga4EfveFdYvdX6Em7rfx vd2g== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr36955376pbc.67.1359370155956; Mon, 28 Jan 2013 02:49:15 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 02:49:15 -0800 (PST) In-Reply-To: <510654FA.5060403@fkie.fraunhofer.de> References: <510654FA.5060403@fkie.fraunhofer.de> Date: Mon, 28 Jan 2013 11:49:15 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V3 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:49:17 -0000 +1 AB On 1/28/13, Henning Rogge wrote: > Hi, > > I made ome small revisions all over the place in the document. > > I think its getting to the point to start an I-D. Just the packet-level > TLV-block compression and some ideas for address compression are still > missing. > > And we have to decide how to transport the compressed data over the > network! > > Henning Rogge > > ----------------------- > > RFC5444 Schema Compression V3 > =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=3D=3D=3D > > Changes since V2: > - explicit "any" placeholder in schema > - usage of RFC6256 > - quantity of address-tlvs "per address" > - added missing message header flag octet in uncompressed example > - more explanation of example compression > - layout cleanup > > Changes since V1: > - restructured text to make it easier to read > - added compression for address-TLVs > - simplified Schema description > (no more differentiation between mandatory and optional TLVs) > - added explanation for TLVs schema fields > > > > Compression idea > ---------------- > > Describe the typical content of a RFC5444 message in your deployment > with a Schema. > > Remove everything from the RFC5444 message that can be constructed from > Schema. Use bitfields to describe how many TLVs of each kind are present > in a TLV-block and their data. > > Use RFC6256 to encode compressable numbers larger than 255. > > > > Schema content > -------------- > > Schema field values can a list of possible values (the list can contain > a single value) or an interval of numbers. Schema fields can be empty > when the field is not restricted by the Schema in any ways and has > always to be fully transmitted over the network. > > > Fields for Message Header: > - each of the fields of the Message Headers schema describes one of the > possible fields described in RFC5444 chapter 5.2 > > > Fields for TLVs: > - "quantity" limits the number of times a TLV can be present in a > TLV-block. The VALIDITY_TIME TLV is mandatory for all NHDP messages and > can only be present once, so its quantity is "1". The INTERVAL_TIME TLV > is optional for NHDP messages, but must not be there more than once, so > its quantity is "0-1". Quantity for address TLVs is PER ADDRESS! > - "extension type" sets the extension type of the TLV if known. > - "value length" restricts the length of the TLVs value in octets (to a > range or a fixed length). > - "value" restricts the value itself of the TLV. > > > > Example schema > -------------- > > Schema Number: 42 > > Message Header: > * Type: 0 > * MHasOrig: 0 > * MHasHopLimit: 1 > * MHasHopCount: 0 > * MHasSeqnum: 1 > * Address Length: 4 > * Originator Address: * > * Hop Limit: 1 > * Hop Count: * > * Sequence Number: * > > Message TLVs: > * TLV type 0: (INTERVAL_TIME) > +-- quantity: 0-1 > +-- extension type: 0 > +-- value length: 1 > +-- value: * > | > * TLV type 1 (VALIDITY_TIME) > +-- quantity: 1 > +-- extension type: 0 > +-- value length: 1 > +-- value: * > > Addresses Block TLVs: > * TLV type 2 (LOCAL_IF) > +-- quantity: 0-1 > +-- extension type: 0 > +-- value length: 1 > +-- value: 0-1 > | > * TLV type 3 (LINK_STATUS) > +-- quantity: 0-1 > +-- extension type: 0 > +-- value length: 1 > +-- value: 0-2 > | > + TLV type 4 (OTHER_NEIGHBOR) > +-- quantity: 0-1 > +-- extension type: 0 > +-- value length: 1 > +-- value: 0-1 > > > > Example message for compression > ------------------------------- > > The message to be compressed in this example is a NHDP message: > - 4-byte addresses, > - hoplimit 1, > - sequence number 0x1234 > > - an INTERVAL_TIME Message-TLV with value 0x02 > - a VALDIITY_TIME Message-TLV with value 0x20 > > - an address block with the IP's 10.0.0.1, 10.0.0.2 and 10.0.0.3 > - 3-byte head (10.0.0), no prefixes > - one LOCAL_IF TLV for index 0 and value 0x00 > - one LINK_STATUS_TLV for indices 1-2 and the values 0x01/0x02 > - one OTHER_NEIGHBOR TLV for indices 1-2 and the values 0x01/0x00 > > > > Example compression > ------------------- > > # The message always starts with the schema number (compressed with > RFC6256). > 42 > > # Add compressed msg-size to message (also compressed with RFC6256). > 17 > > # Skip the msg-flags AND msg-addr-length field if specified in the > schema, otherwise add them to the message. > (none in this example) > > # Add all optional message header fields (Originator, Hoplimit, > Hopcount, Sequence Number) that are marked in the flags and are not > already defined in the schema. > 12 34 (sequence number value) > > # Add a bitfield with as many bits for each TLV as needed to encode the > quantity of it (no bit necessary for one fixed quantity, one bit for > 0-1, ...). Append another bit that encodes if 'other TLVs' will follow > the compressed ones. Append zeros to padd to a full octet. > # If the quantity of a TLV is unrestricted, use RFC6256 to encode the > quantity. > # The order of the TLVs is the same as defined in the schema. > # In this example INTERVAL_TIME can be present 0-1 times and > VALIDITY_TIME is always present once. > > # binary: (1*INTERVAL_TIME, no "other TLVs") > # (1*VALDIITY_TIME is implicitly defined by the schema) > 1 0 > > # in bytes: > 80 > > # Add all present TLVs to the compressed message. Leave out all fields > that can be reconstructed from the Schema. Shorten each TLVs remaining > fields (except tlv-flags) into bitfield as long as the possible > combinations need. Only compress value if can be expressed in less than > 8 bits (padd with zero-bits before the value if not). > > # value of INTERVAL-TIME TLV > 02 > > # value of VALIDITY-TIME TLV > 20 > > # If there are other TLVs (not described in the schema), add the number > of bytes needed to describe them (RFC6256 encoded) and the TLVs itself > (uncompressed). > > (none in this example) > > # Add the uncompressed address-block to the message. > 03 80 03 10 00 00 01 02 03 > > # Add a bitfield with as many bits for each TLV as needed to encode the > quantity of it (no bit necessary for one fixed quantity, one bit for > 0-1, ...). Append another bit that encodes if 'other TLVs' will follow > the compressed ones. Add zeros to padd to a full octet. > # The number of addresses multiplied by the quantity defined in the > schema determines the possible quantities of address TLVs. > # If the quantity of a TLV is unrestricted, use RFC6256 to encode the > quantity. > # The order of the TLVs is the same as defined in the schema. > # In this example all TLVs can be present 0-3 times, which means two > bits are needed to encode the quantity of each compressed address TLV > > # binary: (1*LOCAL_IF, 1*LINK_STATUS, 1*OTHER_NEIGHBOR, no other TLVs) > 01 01 01 0 > > # in bytes: > 54 > > # Add all present TLVs to the compressed message. Leave out all fields > that can be reconstructed from the Schema. Shorten each TLVs remaining > fields (except tlv-flags) into bitfield as long as the possible > combinations need. Only compress value if can be expressed in less than > 8 bits (padd with zero-bits before the value if not). > > # binary: LOCAL_IF flags, index-start and value > 01010000 00 0 > > # binary: LINK_STATUS flags, index-start, index-end and two values > 00110100 01 10 01 10 > > # binary: OTHER_NEIGHBOR flags, index-start, index-end and two values > 00110100 01 10 1 0 > > # in bytes: > 50 00 > 34 66 > 34 68 > > # If there are other TLVs (not described in the schema), add the number > of bytes needed to describe them (RFC6256 encoded) and the TLVs itself > (uncompressed). > (none in this example) > > > > Result > ------ > > The complete message has been reduced from > > 00 53 00 30 53 01 12 34 (message header) > 00 08 (message-tlv block length) > 00 10 01 02 (INTERVAL-TIME 0x01) > 01 10 01 20 (VALIDITY-TIME 0x10) > 03 80 03 10 00 00 01 02 03 (3 Addresses, 10.0.0.1,.2 and .3, no prefixes) > 00 13 (address-tlv block length) > 02 50 01 01 00 (LOCAL_IF index=3D1 0x00) > 03 34 02 03 01 01 02 (LINK_STATUS index=3D2-3 0x01/0x02) > 04 34 02 03 01 01 00 (OTHER_NEIGHBOR index=3D2-3 0x01/0x00) > > (a total of 48 bytes) > > to > > 42 17 12 34 (message header) > 80 02 20 (message tlvs) > 03 80 03 10 00 00 01 02 03 (address block) > 54 50 00 34 66 34 68 (address tlvs) > > (a total of 23 bytes) > > > > Comments > -------- > > A packet-level schema entry should be added to this concept. > > I think there could be some more compression if the Schema includes a > "known prefix" for all addresses (or maybe a list of them?). This would > help to compress both the originator address and the prefix fields in > address blocks. > > In theory there are a few wasted bits here and there, but I decided NOT > to do any bit-shifting on data which is larger than 1 byte. > > A great addition to this idea would be a protocol for requesting unknown > schema from your neighbor. And a program that scans a RFC5444 stream and > suggests a schema based on the watched messages. > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From rick.taylor@cassidian.com Mon Jan 28 02:56:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5B21F882E for ; Mon, 28 Jan 2013 02:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMkusr24zHUx for ; Mon, 28 Jan 2013 02:56:56 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id DE6C421F84B6 for ; Mon, 28 Jan 2013 02:56:54 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 28 Jan 2013 11:56:52 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 28 Jan 2013 11:57:00 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 11:56:44 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 11:56:44 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:56:43 +0000 From: "Taylor, Rick" To: Henning Rogge , Teco Boot Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN+zZm0Kecgy25ek6rKwG50GyxMJhej6Hg Date: Mon, 28 Jan 2013 10:56:42 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2013 10:56:44.0204 (UTC) FILETIME=[290F9EC0:01CDFD46] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19594.006 X-TM-AS-Result: No--55.866900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:56:57 -0000 +1 for RFC6256 - and thanks for drawing my attention to it Teco, I had used= it elsewhere without realising there was an RFC. I do have a concern with schema compression at the packet level. In order = to maintain backwards compatibility, any packet received by a compliant RFC= 5444 parser must be able to determine the and total-length o= f each message in the packet *even if schema-compressed*, just for the purp= oses of discarding the message if it is not a handled type. If you ignore such back-compatibility then you are forced into using a sepa= rate port for schema-compression and I would much rather see schema-compres= sion developed as a backwards-compatible extension to the RFC5444 message f= ormat, than a separate meta-protocol. That being said, I am in favour of schema-compression, but only if it can b= e made to play nicely with RFC5444. I also have some concerns over formal schema definition 'languages'. Althou= gh I hate them for their pedantry, I do see the need for them. May I sugge= st using an XML format for formal specification of schemas, as I think ther= e might be a danger trying to invent our own schema definition syntax that = just adds complexity. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 25 January 2013 19:59 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] RFC5444 schema-based compression V2 > > On Fri, Jan 25, 2013 at 7:07 PM, Dearlove, Christopher (UK) > wrote: > > If we are using this for lengths - of messages, TLV blocks etc. I > sincerely hope we never see a value as high as 0xFF00. > > For length and maybe for the Schema-ID itself. > > > (I don't think we are planning to use it for two byte values that aren'= t > weighted low in that manner (i.e. not for sequence numbers etc.) > > Yes, that would be stupid to do. > > But I am currently thinking about a few additions to help with address > compression. > > Henning Rogge > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] > > Sent: 25 January 2013 15:27 > > To: Henning Rogge > > Cc: Dearlove, Christopher (UK); manet@ietf.org > > Subject: Re: [manet] RFC5444 schema-based compression V2 > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > I'm fine as long as it is unlikely to face higher overhead encoding for > values that are frequently used. My worries are for the 0xFFxx range. > > > > Teco > > > > Op 25 jan. 2013, om 16:20 heeft Henning Rogge het volgende geschreven: > > > >> On 01/25/2013 01:22 PM, Teco Boot wrote: > >>> There is the SDNV-8/-16 method. Maybe leave this open and use the > schema to select. > >> > >> After looking through RFC6256, I think we could easily use this one. > The one-byte more overhead for TLV-blocks longer than 16K Byte is not > really that relevant. > >> > >> Henning Rogge > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >> > > > > > > > > ******************************************************************** > > 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://www.ietf.org/mailman/listinfo/manet > > > > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Mon Jan 28 03:31:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4159821F87FA for ; Mon, 28 Jan 2013 03:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsZ8+EMhVZd0 for ; Mon, 28 Jan 2013 03:31:03 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9104221F87DF for ; Mon, 28 Jan 2013 03:31:02 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TzmvV-0001z4-QX for manet@ietf.org; Mon, 28 Jan 2013 12:31:01 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TzmvV-0006M6-Ns for manet@ietf.org; Mon, 28 Jan 2013 12:31:01 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 28 Jan 2013 12:31:01 +0100 Message-ID: <51066170.6030900@fkie.fraunhofer.de> Date: Mon, 28 Jan 2013 12:30:56 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050200040409080003060109" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16578/Sun Jan 27 17:03:40 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 63d11b563531d75ada9d42d73b6da78e Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:31:04 -0000 --------------ms050200040409080003060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/28/2013 11:56 AM, Taylor, Rick wrote: > I do have a concern with schema compression at the packet level. In > order to maintain backwards compatibility, any packet received by a > compliant RFC5444 parser must be able to determine the > and total-length of each message in the packet *even if > schema-compressed*, just for the purposes of discarding the message > if it is not a handled type. I don't think the current idea supports mixing compressed and=20 uncompressed messages in the same packet. There is also no bit left in=20 the message-header flags we could use to mark "this is compressed". But one way to determine "this is compressed" might be the packetbb=20 version number. > If you ignore such back-compatibility then you are forced into using > a separate port for schema-compression and I would much rather see > schema-compression developed as a backwards-compatible extension to > the RFC5444 message format, than a separate meta-protocol. I don't think IANA will give us another port/ip-protocol number, just=20 for a compressed format. But we still have to think about how to transmit it over the network. > That being said, I am in favour of schema-compression, but only if it > can be made to play nicely with RFC5444. +1 > I also have some concerns over formal schema definition 'languages'. > Although I hate them for their pedantry, I do see the need for them. > May I suggest using an XML format for formal specification of > schemas, as I think there might be a danger trying to invent our own > schema definition syntax that just adds complexity. I have already played with the idea of using ABNF (RFC5234) to specify=20 the schema format. XML would also work, but we might also need a binary=20 representation of the schema if we want to transmit it over the network. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050200040409080003060109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjgxMTMwNTlaMCMGCSqGSIb3DQEJBDEWBBSJHcpN6EZYC0bcn08HBHwjM5r9FjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAkoYcjD31PQfyvVh0Wk81iMdUmZCEywIgTP6M2o5Tm4dE OdpCNZEOJ5cY0fygHOODBku4sZYwp/RYt1y4DZUw95YKF6qiq0SU2ocfO4p+z3S9MxuGjyol zs6cNz5R8x2L6tSTzyyUjtREH0/9n/K36ukw+AJzxPSzGCl9PKBLN4qPDTppkVrreuPkCkJ8 VpolAAhtT2G5/5WHJ3AiiExaOOlWXMDtXUwA53AzvQTAF/WCD07I9sJlexHN1Dt2lp//dZC7 j6XmCepFV2QzaMbpqYunG8xYHM90jsRegJxafoNehx4aTU7a2coQ33+EiiJaLIFR0PsV3FFa cit/uN9v6QAAAAAAAA== --------------ms050200040409080003060109-- From rick.taylor@cassidian.com Mon Jan 28 03:45:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3467621F8816 for ; Mon, 28 Jan 2013 03:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okgWE2i6V5wg for ; Mon, 28 Jan 2013 03:45:44 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id D1FF121F884B for ; Mon, 28 Jan 2013 03:45:43 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 28 Jan 2013 12:45:43 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 28 Jan 2013 12:45:57 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 12:45:41 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 12:45:41 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 11:45:34 +0000 From: "Taylor, Rick" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] RFC5444 schema-based compression - compatibility Thread-Index: AQHN/Uz7M7+JtMfdaEKSNWIfCADK+A== Date: Mon, 28 Jan 2013 11:45:33 +0000 Message-ID: References: <814cb775-f853-4ea5-9ee2-e4a72862bf2c@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <814cb775-f853-4ea5-9ee2-e4a72862bf2c@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2013 11:45:41.0563 (UTC) FILETIME=[FFDD08B0:01CDFD4C] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19594.006 X-TM-AS-Result: No--9.065400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] RFC5444 schema-based compression - compatibility X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:45:45 -0000 Just a few quick ideas for backwards and forwards compatibility between RFC= 5444 and schema-compression: If the RFC5444 is extended to use bit 2 (currently unused/igno= red) to indicate that there are further schema-compressed message-blocks AF= TER the RFC544 uncompressed message-blocks in the message then backwards co= mpatibility is provided. However, a strictly compliant RFC5444 version 0 pa= rser will error when encountering the extra bytes found after the last vers= ion 0 message-block, breaking forwards compatibility (See section 5.1 in RF= C5444). One possibility to maintain forwards compatibility would be to encode each = schema-compressed message block as a version-0 packet-TLV, with a reserved = packet-level TLV type, and using the tlv-flags to indicate length (the mult= i-value bits are not used). Obviously if both ends of a conversation are both version-1 compliaint then= using bit-2 in results in better compression. My question to the list is: Is forwards compatibility from RFC5444 version = 0 important, or are people happy with producing RFC5444-version-1 that is b= ackwards compatible, but will break a purely version-0 complaint parser? Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Mon Jan 28 03:55:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345C221F886F for ; Mon, 28 Jan 2013 03:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY-C3HG9lKKW for ; Mon, 28 Jan 2013 03:55:39 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 926F821F8865 for ; Mon, 28 Jan 2013 03:55:38 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TznJJ-0000rS-Eb; Mon, 28 Jan 2013 12:55:37 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TznJJ-00072G-Bt; Mon, 28 Jan 2013 12:55:37 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 28 Jan 2013 12:55:36 +0100 Message-ID: <51066738.4050208@fkie.fraunhofer.de> Date: Mon, 28 Jan 2013 12:55:36 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Taylor, Rick" References: <814cb775-f853-4ea5-9ee2-e4a72862bf2c@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020909030000080704040707" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16578/Sun Jan 27 17:03:40 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2abfdf9e49f4c2a9c8f5f354a342600b Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression - compatibility X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:55:40 -0000 --------------ms020909030000080704040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/28/2013 12:45 PM, Taylor, Rick wrote: > Just a few quick ideas for backwards and forwards compatibility > between RFC5444 and schema-compression: > > If the RFC5444 is extended to use bit 2 (currently > unused/ignored) to indicate that there are further schema-compressed > message-blocks AFTER the RFC544 uncompressed message-blocks in the > message then backwards compatibility is provided. However, a strictly > compliant RFC5444 version 0 parser will error when encountering the > extra bytes found after the last version 0 message-block, breaking > forwards compatibility (See section 5.1 in RFC5444). I like the idea using the unused packet-header flags bit, but=20 unfortunately what you suggest doesn't seem to be possible because there = is no length field in the packet header. This means a parser that doesn't know the "compressed" bit will not be=20 able to determine how many uncompressed messages are in the packet. The other problem is that RFC5444 specifies that parsers should IGNORE=20 these two unused bits, they do not throw packets away if they are not zer= o. > One possibility to maintain forwards compatibility would be to encode > each schema-compressed message block as a version-0 packet-TLV, with > a reserved packet-level TLV type, and using the tlv-flags to indicate > length (the multi-value bits are not used). This sounds like a waste of bytes for compressed packets. And a bad=20 style too. > Obviously if both ends of a conversation are both version-1 > compliaint then using bit-2 in results in better > compression. Yes. > My question to the list is: Is forwards compatibility from RFC5444 > version 0 important, or are people happy with producing > RFC5444-version-1 that is backwards compatible, but will break a > purely version-0 complaint parser? I think the compressed version should make a standard compliant RFC5444=20 parser to DROP the packet. For proactive protocols we could define a packet-level protocol which=20 can determine if neighbors support compression or not, but this is=20 difficult for reactive ones. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020909030000080704040707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjgxMTU1MzZaMCMGCSqGSIb3DQEJBDEWBBSO73Pf00awpEZ+ZBChyG6MUvOB+zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAU47MDersEH+J4wULkBKJuqXAyLGPuO1eWKiLZug94XnQ wXnbTsZLSMMjDxKxFrf/0Ego13pF5zihbDHfmROGTvXNB3JDxbdd9xfJpm6XdXPfREufg0XZ 6QxP/tfr6IjVRlIiYVH721FYsinGEzMOkRYkE46HFmrtvNIH6tG6ZGDluj97n98FSOL9HwdA zpW9HEdLqJGmt3y557AiYnTBPlJvGcNF15kOaVY2n5CjBhwkyEOMwTfIKA+i3ZFivVSVTgRq e2QgV/czoMote/wLsOuMH9oAmTztiJ2fseDfle/fDljOOmWseNdi05cv84AeBvvkkQsmXTof uNKIW1EwugAAAAAAAA== --------------ms020909030000080704040707-- From rick.taylor@cassidian.com Mon Jan 28 03:57:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317D621F879A for ; Mon, 28 Jan 2013 03:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBj9xMB0rEY7 for ; Mon, 28 Jan 2013 03:57:36 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1223321F85FE for ; Mon, 28 Jan 2013 03:57:35 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 28 Jan 2013 12:57:35 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 28 Jan 2013 12:57:34 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 12:57:34 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 12:57:34 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 11:57:33 +0000 From: "Taylor, Rick" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN/Urw0Kecgy25ek6rKwG50GyxMJhen2TQ Date: Mon, 28 Jan 2013 11:57:33 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2013 11:57:34.0320 (UTC) FILETIME=[A8B31F00:01CDFD4E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19594.006 X-TM-AS-Result: No--34.048800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:57:37 -0000 My 'off-the-cuff' thoughts on schema discovery: Specify an optional RFC5444 TLV to be allowed in schema-compressed message = blocks that contains the URL that hosts the schema definition 'document' (a= nother advantage for XML). The URL could just refer to an FTP or HTTP serv= ice on the sender for private networks. This would allow retrieval and/or extended validation of schemas by full-fe= atured parsers (useful for a development environment) but not require suppo= rt in all parsers (good for embedded devices) and act a little like namespa= ces in XML. Embedding entire schemas within RFC5444 messages just seems too 'heavy', so= me level of indirection seems better. It avoids "give me the latest schema= text" transactions over datagram transport. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 28 January 2013 11:31 > To: manet@ietf.org > Subject: Re: [manet] RFC5444 schema-based compression V2 > > On 01/28/2013 11:56 AM, Taylor, Rick wrote: > > I do have a concern with schema compression at the packet level. In > > order to maintain backwards compatibility, any packet received by a > > compliant RFC5444 parser must be able to determine the > > and total-length of each message in the packet *even if > > schema-compressed*, just for the purposes of discarding the message > > if it is not a handled type. > > I don't think the current idea supports mixing compressed and > uncompressed messages in the same packet. There is also no bit left in > the message-header flags we could use to mark "this is compressed". > > But one way to determine "this is compressed" might be the packetbb > version number. > > > If you ignore such back-compatibility then you are forced into using > > a separate port for schema-compression and I would much rather see > > schema-compression developed as a backwards-compatible extension to > > the RFC5444 message format, than a separate meta-protocol. > > I don't think IANA will give us another port/ip-protocol number, just > for a compressed format. > > But we still have to think about how to transmit it over the network. > > > That being said, I am in favour of schema-compression, but only if it > > can be made to play nicely with RFC5444. > > +1 > > > I also have some concerns over formal schema definition 'languages'. > > Although I hate them for their pedantry, I do see the need for them. > > May I suggest using an XML format for formal specification of > > schemas, as I think there might be a danger trying to invent our own > > schema definition syntax that just adds complexity. > > I have already played with the idea of using ABNF (RFC5234) to specify > the schema format. XML would also work, but we might also need a binary > representation of the schema if we want to transmit it over the network. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Mon Jan 28 04:16:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472D421F87FA for ; Mon, 28 Jan 2013 04:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evdyRtVEEIJT for ; Mon, 28 Jan 2013 04:16:09 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59621F884B for ; Mon, 28 Jan 2013 04:16:09 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tznd9-0007qS-5y; Mon, 28 Jan 2013 13:16:07 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tznd9-0007aU-3G; Mon, 28 Jan 2013 13:16:07 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 28 Jan 2013 13:16:06 +0100 Message-ID: <51066C05.1060106@fkie.fraunhofer.de> Date: Mon, 28 Jan 2013 13:16:05 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Taylor, Rick" References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050704060209030306050700" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16578/Sun Jan 27 17:03:40 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 43fe4b22ce746091c894ec5715882e1d Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 12:16:10 -0000 --------------ms050704060209030306050700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/28/2013 12:57 PM, Taylor, Rick wrote: > My 'off-the-cuff' thoughts on schema discovery: > > Specify an optional RFC5444 TLV to be allowed in schema-compressed > message blocks that contains the URL that hosts the schema definition > 'document' (another advantage for XML). The URL could just refer to > an FTP or HTTP service on the sender for private networks. I don't think FTP or HTTP are a good idea in this context. RFC5444 is made for transmitting packets/messages of ROUTING protocols. If a node cannot understand this because of a missing schema, it will=20 not have access to any services except the one the neighbors provide. > This would allow retrieval and/or extended validation of schemas by > full-featured parsers (useful for a development environment) but not > require support in all parsers (good for embedded devices) and act a > little like namespaces in XML. > Embedding entire schemas within RFC5444 messages just seems too > 'heavy', some level of indirection seems better. It avoids "give me > the latest schema text" transactions over datagram transport. I think a binary format for the schemas would be a good idea (in=20 addition to a normal "text form" ?). This would also solve the transmission problem. Most schemas will be=20 pretty short, I don't see a problem transmitting them in a single UDP=20 packet, maybe even encapsulated in a RFC5444 packet-TLV or a special=20 (and uncompressed) RFC5444 message.. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050704060209030306050700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjgxMjE2MDVaMCMGCSqGSIb3DQEJBDEWBBTjjHmCXTyvbbLMpVlXcl8mN7VqhDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEARrpNuhEp6ZT/e9qEcFQ0M/NEBkeTfRGF5YHhWY6zEmRI sUjkxWorR9OHzr+BD+WOHgb3seJBvtcDauiRYSg6uC+oEKxitJcJOrO4jdmM8mVLJc0OGcke dEKyUQePw1x9+JVgZZkI3cb5sUXKEBd++OxTPcjgHRSCkqOqxCMULCnYSZE1Zlfyvo8G2xBd 7ZLOhgRYLHV73KVA9ErKrc1Uowq8V/0wNqkCo6op5f1znMFFBGPkEaQbLvGTVK5G99oU0UX4 p6V1jzrNgktaXEKXiYfGYRyAW5NYgZU9MauHNHfXqs0vQifgxEuOAC3dYvnPNdHSSQGBy55W 8/ggFvO4ggAAAAAAAA== --------------ms050704060209030306050700-- From rick.taylor@cassidian.com Mon Jan 28 04:16:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1667B21F8889 for ; Mon, 28 Jan 2013 04:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hhEVUohHx0s for ; Mon, 28 Jan 2013 04:16:19 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5521F87FA for ; Mon, 28 Jan 2013 04:16:18 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 28 Jan 2013 13:16:15 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 28 Jan 2013 13:16:30 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 13:16:15 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 13:16:15 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 12:16:14 +0000 From: "Taylor, Rick" To: Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression - compatibility Thread-Index: AQHN/U8Gpnjr8Zcxo0C4+gjoYaBBaphepDVQ Date: Mon, 28 Jan 2013 12:16:13 +0000 Message-ID: References: <814cb775-f853-4ea5-9ee2-e4a72862bf2c@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2013 12:16:15.0079 (UTC) FILETIME=[44B95F70:01CDFD51] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19594.007 X-TM-AS-Result: No--33.727400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression - compatibility X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 12:16:20 -0000 > On 01/28/2013 12:45 PM, Taylor, Rick wrote: > > Just a few quick ideas for backwards and forwards compatibility > > between RFC5444 and schema-compression: > > > > If the RFC5444 is extended to use bit 2 (currently > > unused/ignored) to indicate that there are further schema-compressed > > message-blocks AFTER the RFC544 uncompressed message-blocks in the > > message then backwards compatibility is provided. However, a strictly > > compliant RFC5444 version 0 parser will error when encountering the > > extra bytes found after the last version 0 message-block, breaking > > forwards compatibility (See section 5.1 in RFC5444). > > I like the idea using the unused packet-header flags bit, but > unfortunately what you suggest doesn't seem to be possible because there > is no length field in the packet header. > > This means a parser that doesn't know the "compressed" bit will not be > able to determine how many uncompressed messages are in the packet. > > The other problem is that RFC5444 specifies that parsers should IGNORE > these two unused bits, they do not throw packets away if they are not > zero. One potential solution would be to add a NUL message-block (length =3D 0, 4= bytes) to mark the end of the version-0 message-blocks, and the start of t= he schema-compressed blocks. Not nice, and adds 4 bytes, and it still brea= ks version-0 parsers, but does allow a mix-and-match approach and general-p= urpose parsers. Unfortunately there are no unused bits in the message header - these would = be ideal for classifying the message-block format. > > One possibility to maintain forwards compatibility would be to encode > > each schema-compressed message block as a version-0 packet-TLV, with > > a reserved packet-level TLV type, and using the tlv-flags to indicate > > length (the multi-value bits are not used). > > This sounds like a waste of bytes for compressed packets. And a bad > style too. Agreed, it's not the nicest solution, but it does allow schema-compressed m= essages to be handled safely by a pre version-0 parser, at a cost of 3 or 4= bytes per schema-compressed message-block. This is very much a work-aroun= d but it does allow best compatibility. > > Obviously if both ends of a conversation are both version-1 > > compliaint then using bit-2 in results in better > > compression. > > Yes. And some higher-level negotiation can occur to achieve this. > > > My question to the list is: Is forwards compatibility from RFC5444 > > version 0 important, or are people happy with producing > > RFC5444-version-1 that is backwards compatible, but will break a > > purely version-0 complaint parser? > > I think the compressed version should make a standard compliant RFC5444 > parser to DROP the packet. I'm not sure if there are protocols in the reactive space that would like m= essages to be forwarded even if they are not understood by the intermediate= node, or is that more relevant to optional TKLVs? > For proactive protocols we could define a packet-level protocol which > can determine if neighbors support compression or not, but this is > difficult for reactive ones. As I said above, I think this is out of scope for RFC5444, some higher leve= l protocol can determine this. Capability negotiation is a real can of wor= ms. Does the packetbb security RFC go into this at all? Rick Taylor > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From rick.taylor@cassidian.com Mon Jan 28 05:17:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6621F841F for ; Mon, 28 Jan 2013 05:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi8gzgeL5sqA for ; Mon, 28 Jan 2013 05:17:51 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5521F841C for ; Mon, 28 Jan 2013 05:17:50 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 28 Jan 2013 14:17:48 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 28 Jan 2013 14:17:48 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 14:17:48 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 14:17:48 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 13:17:47 +0000 From: "Taylor, Rick" To: Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression V2 Thread-Index: AQHN/Urw0Kecgy25ek6rKwG50GyxMJheqDpNgAALoZA= Date: Mon, 28 Jan 2013 13:17:47 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2013 13:17:48.0008 (UTC) FILETIME=[DDE19E80:01CDFD59] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19594.007 X-TM-AS-Result: No--31.209700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:17:52 -0000 > > Specify an optional RFC5444 TLV to be allowed in schema-compressed > > message blocks that contains the URL that hosts the schema definition > > 'document' (another advantage for XML). The URL could just refer to > > an FTP or HTTP service on the sender for private networks. > > I don't think FTP or HTTP are a good idea in this context. > > RFC5444 is made for transmitting packets/messages of ROUTING protocols. I agree: RFC5444 is for ROUTING protocol messages, not meta-information mes= sages. I would always want to move meta-information out-of-band. As I see it, either the schema is fixed (as in a final protocol) in which c= ase the schema is documented and widely available, and all participants use= the correct final version, or the schema is in flux (as in a prototype or = development scenario) in which case participants need a method to check if = they have a valid schema for compression/decompression. In this later case= I see it as perfectly sensible that the retrieval of the schema is out of = band - either the parser does something automated to get and parse the sche= ma, or it just errors with "Mismatched or unknown schema". Adding the extra specification to cover the transmission of schema meta-inf= ormation within RFC5444 is just making extra work for yourself. I would mu= ch rather see a simple/flexible/lightweight solution such as an optional me= ssage-tlv that held a reference to the schema, rather than specifying an RF= C5444 compliant schema format. HTTP and FTP a perfectly sensible transport= mechanisms, and in a production environment one would not want dynamically= updating schemas anyway, so they would be disabled in the parser. > If a node cannot understand this because of a missing schema, it will > not have access to any services except the one the neighbors provide. In an embedded device this might be exactly what is desired. In a fuller-fe= atured device being able to use HTTP or FTP (or whatever out-of-band mechan= ism is required) may be practical, allowing much more flexibility. > > > This would allow retrieval and/or extended validation of schemas by > > full-featured parsers (useful for a development environment) but not > > require support in all parsers (good for embedded devices) and act a > > little like namespaces in XML. > > > Embedding entire schemas within RFC5444 messages just seems too > > 'heavy', some level of indirection seems better. It avoids "give me > > the latest schema text" transactions over datagram transport. > > I think a binary format for the schemas would be a good idea (in > addition to a normal "text form" ?). I think it would make any schema compression RFC longer, harder to ratify a= nd harder to implement. I just don't see the need. Let's reuse ABNF or XM= L or something (almost) human readable and keep the data out-of-band. Bina= ry formats shouldn't be transmitted and are implementation details for the = parser developers. > This would also solve the transmission problem. Most schemas will be > pretty short, I don't see a problem transmitting them in a single UDP > packet, maybe even encapsulated in a RFC5444 packet-TLV or a special > (and uncompressed) RFC5444 message.. But then someone asks about reliability, and we end up building TCP/RFC5444= /IP and that takes 4 years to reach an uneasy consensus... ;) Rick Taylor > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Tue Jan 29 00:14:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81121F8A77 for ; Tue, 29 Jan 2013 00:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK7eBCydepEs for ; Tue, 29 Jan 2013 00:14:12 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B4AF321F8A4F for ; Tue, 29 Jan 2013 00:14:11 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U06KY-00048A-Jq; Tue, 29 Jan 2013 09:14:10 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U06KY-0007Iw-H7; Tue, 29 Jan 2013 09:14:10 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Jan 2013 09:14:10 +0100 Message-ID: <510784CA.9000409@fkie.fraunhofer.de> Date: Tue, 29 Jan 2013 09:14:02 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Taylor, Rick" References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030102040203060005080602" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16584/Tue Jan 29 08:37:32 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: bde457e082b6573242c43f66a8a95436 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 08:14:13 -0000 --------------ms030102040203060005080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/28/2013 01:16 PM, Taylor, Rick wrote:>> On 01/28/2013 12:45 PM, Taylor, Rick wrote: > One potential solution would be to add a NUL message-block (length =3D > 0, 4 bytes) to mark the end of the version-0 message-blocks, and > the start of the schema-compressed blocks. Not nice, and adds 4 > bytes, and it still breaks version-0 parsers, but does allow a > mix-and-match approach and general-purpose parsers. If we are willing to break compatibility, we can easily add a "number of uncompressed/compressed messages" byte into the message. No need for some hack with a message with zero length (which would not be valid RFC5444 anyways). > Agreed, it's not the nicest solution, but it does allow > schema-compressed messages to be handled safely by a pre version-0 > parser, at a cost of 3 or 4 bytes per schema-compressed > message-block. This is very much a work-around but it does allow best > compatibility. I don't think its worth the effort. > As I said above, I think this is out of scope for RFC5444, some > higher level protocol can determine this. I don't like the idea bootstrapping a lowlevel protocol with a highlevel = one. > Does the packetbb security RFC go into this at all? No. On 01/28/2013 02:17 PM, Taylor, Rick wrote: > I agree: RFC5444 is for ROUTING protocol messages, not > meta-information messages. I would always want to move > meta-information out-of-band. Its still routing information, so I think RFC5444 could be a place for=20 this. It would also solve the bootstrap problem easily. > As I see it, either the schema is fixed (as in a final protocol) in > which case the schema is documented and widely available, and all > participants use the correct final version, or the schema is in flux > (as in a prototype or development scenario) in which case > participants need a method to check if they have a valid schema for > compression/decompression. In this later case I see it as perfectly > sensible that the retrieval of the schema is out of band - either the > parser does something automated to get and parse the schema, or it > just errors with "Mismatched or unknown schema". Errors like this in a routing protocol are a good way to break your=20 manet apart. > Adding the extra specification to cover the transmission of schema > meta-information within RFC5444 is just making extra work for > yourself. I would much rather see a simple/flexible/lightweight > solution such as an optional message-tlv that held a reference to > the schema, rather than specifying an RFC5444 compliant schema > format. HTTP and FTP a perfectly sensible transport mechanisms, and > in a production environment one would not want dynamically updating > schemas anyway, so they would be disabled in the parser. I am not sure "lightweight" and HTTP/FTP mix well in a Manet. In addition to this including a full URL "where to download the schema"=20 into a RFC5444 message/packet would be a huge waste of bytes. >> I think a binary format for the schemas would be a good idea (in >> addition to a normal "text form" ?). > > I think it would make any schema compression RFC longer, harder to > ratify and harder to implement. I just don't see the need. Let's > reuse ABNF or XML or something (almost) human readable and keep the > data out-of-band. I don't agree here, but we have to see the final structure of a schema=20 before we can decide on this. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030102040203060005080602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjkwODE0MDdaMCMGCSqGSIb3DQEJBDEWBBS8+x1r/qoLiGkILfyCyNsctF9okjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEANdQh1Btx5PQ/3azm7nzNp0D2mhxnGTpIv+Z2DtkMdx60 RVL6wJFfzLbWMPYnIVAES12fxw6cJ7ULWTTNgGJV/pzNTW0i4sVrdJ+/e2gpQyeezrWid0ez mTEvNB920dAY9ps8IQ5UYUSCKXXNw4WpwI+mXrJ255h5d1AsjlzeLz23VehhhWW+v7b2zDxQ 8UXtvMK8qKv/1H4nniKht+tAiLHKNHiLctKrGBgRQ48bMYMFhG5S/1DeKuvzAoYuuNLKHkom 9MCMYsm9mqlqel+D6lIGgthIFBUg8uFIffYbOD6O3k/qfpYe+F4sWq7FrH7ScXQRGtllybib cMKp5TNj/QAAAAAAAA== --------------ms030102040203060005080602-- From christopher.dearlove@googlemail.com Tue Jan 29 00:41:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29121F881C for ; Tue, 29 Jan 2013 00:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLJE8W8XDxYY for ; Tue, 29 Jan 2013 00:41:17 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 136CA21F863C for ; Tue, 29 Jan 2013 00:41:16 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn3so147888wib.11 for ; Tue, 29 Jan 2013 00:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=8vXy588YxBHetAAE+CjbfWo71BPeAkxmT+XbnBpg/cQ=; b=R/ut8fhnp7sgX4KIAEigilSxVAFzGluVn1vhiHKNKlvzQXnb8aBK8Pnb4u2Zxm5igq 5RjjaLYPdZZeueQaBBHbFt6v2Gf/bkOXXlewfJDIWQHEqAEMxzWD9Dm0W8hS43PSpgKt dvUpNtxepLLv+AR1jIqZ4/tJ9zoqdftnshWVLP51eata72aRnF5neZgSywLe8ZoXRpnU BRB04KvBDa39BVAXi78j9HropSqtKXD3+7GpX0dUISYl7ieDxFlgxtxNaI4xU+fi/pKj FPhqovIjoGvyc6LPjvzH0WX275e5/gUCb13eWSAad4hRtAuj5mUq5AXRCXNJViCjB37i 9foA== X-Received: by 10.180.90.106 with SMTP id bv10mr620108wib.12.1359448876203; Tue, 29 Jan 2013 00:41:16 -0800 (PST) Received: from [192.168.254.5] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPS id fx5sm2230136wib.11.2013.01.29.00.41.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 00:41:15 -0800 (PST) References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> <510784CA.9000409@fkie.fraunhofer.de> In-Reply-To: <510784CA.9000409@fkie.fraunhofer.de> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <32A3BE87-988D-457F-8526-93BD712D1A7D@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Tue, 29 Jan 2013 08:42:02 +0000 To: Henning Rogge Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 08:41:18 -0000 I've yet to form a definite opinion on this work, but I have one definite op= inion. No breaking compatibility. A minimum requirement is if version is zer= o, no changes to format. And creating a version one has definite issues that= 's part of my yet to firm a definite opinion. (As do other solutions - encap= sulating in TLV, link layer changes.)=20 -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 29 Jan 2013, at 08:14, Henning Rogge w= rote: > On 01/28/2013 01:16 PM, Taylor, Rick wrote:>> On 01/28/2013 12:45 PM, > Taylor, Rick wrote: >> One potential solution would be to add a NUL message-block (length =3D >> 0, 4 bytes) to mark the end of the version-0 message-blocks, and >> the start of the schema-compressed blocks. Not nice, and adds 4 >> bytes, and it still breaks version-0 parsers, but does allow a >> mix-and-match approach and general-purpose parsers. >=20 > If we are willing to break compatibility, we can easily add a "number of > uncompressed/compressed messages" byte into the message. No need for > some hack with a message with zero length (which would not be valid > RFC5444 anyways). >=20 >> Agreed, it's not the nicest solution, but it does allow >> schema-compressed messages to be handled safely by a pre version-0 >> parser, at a cost of 3 or 4 bytes per schema-compressed >> message-block. This is very much a work-around but it does allow best >> compatibility. >=20 > I don't think its worth the effort. >=20 >> As I said above, I think this is out of scope for RFC5444, some >> higher level protocol can determine this. >=20 > I don't like the idea bootstrapping a lowlevel protocol with a highlevel o= ne. >=20 > > Does the packetbb security RFC go into this at all? >=20 > No. >=20 >=20 >=20 > On 01/28/2013 02:17 PM, Taylor, Rick wrote: >> I agree: RFC5444 is for ROUTING protocol messages, not >> meta-information messages. I would always want to move >> meta-information out-of-band. >=20 > Its still routing information, so I think RFC5444 could be a place for thi= s. It would also solve the bootstrap problem easily. >=20 >> As I see it, either the schema is fixed (as in a final protocol) in >> which case the schema is documented and widely available, and all >> participants use the correct final version, or the schema is in flux >> (as in a prototype or development scenario) in which case >> participants need a method to check if they have a valid schema for >> compression/decompression. In this later case I see it as perfectly >> sensible that the retrieval of the schema is out of band - either the >> parser does something automated to get and parse the schema, or it >> just errors with "Mismatched or unknown schema". >=20 > Errors like this in a routing protocol are a good way to break your manet a= part. >=20 >> Adding the extra specification to cover the transmission of schema >> meta-information within RFC5444 is just making extra work for >> yourself. I would much rather see a simple/flexible/lightweight >> solution such as an optional message-tlv that held a reference to >> the schema, rather than specifying an RFC5444 compliant schema >> format. HTTP and FTP a perfectly sensible transport mechanisms, and >> in a production environment one would not want dynamically updating >> schemas anyway, so they would be disabled in the parser. >=20 > I am not sure "lightweight" and HTTP/FTP mix well in a Manet. >=20 > In addition to this including a full URL "where to download the schema" in= to a RFC5444 message/packet would be a huge waste of bytes. >=20 >>> I think a binary format for the schemas would be a good idea (in >>> addition to a normal "text form" ?). >>=20 >> I think it would make any schema compression RFC longer, harder to >> ratify and harder to implement. I just don't see the need. Let's >> reuse ABNF or XML or something (almost) human readable and keep the >> data out-of-band. >=20 > I don't agree here, but we have to see the final structure of a schema bef= ore we can decide on this. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Tue Jan 29 02:37:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD65D21F84EB for ; Tue, 29 Jan 2013 02:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHW1BE04y8Am for ; Tue, 29 Jan 2013 02:37:50 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5821F84E3 for ; Tue, 29 Jan 2013 02:37:46 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 29 Jan 2013 11:37:28 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 29 Jan 2013 11:37:28 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 11:37:27 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 11:37:27 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:37:27 +0000 From: "Taylor, Rick" To: Christopher Dearlove , Henning Rogge Thread-Topic: [manet] RFC5444 schema-based compression - compatibility Thread-Index: AQHN/gyh8fsVjmhyUkaRwuwjys+6Kg== Date: Tue, 29 Jan 2013 10:37:27 +0000 Message-ID: References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> <510784CA.9000409@fkie.fraunhofer.de> <55d4626e-2265-4ddf-9b85-bbc54dc146bf@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <55d4626e-2265-4ddf-9b85-bbc54dc146bf@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2013 10:37:27.0701 (UTC) FILETIME=[A2250450:01CDFE0C] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19596.006 X-TM-AS-Result: No--33.391300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression - compatibility X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:37:52 -0000 I think we are all agreed that breaking RFC5444 is not an option. My questions and comments were more about compatibility between RFC5444 and= schema-compression, and the options I see are: A) No compatibility - schema-compression feels like RFC5444 but is sufficie= ntly different to require a different parser to use. B) Backwards compatible - A schema-compression parser can parse RFC5444 and= schema-compressed packets. C) Forwards compatible - An RFC5444 parser can parse a packet containing sc= hema-compressed messages, handling unrecognised messages according to the r= ules of RFC5444. All my suggestions so far have been directed at solving options B and C. T= he suggestions do come at a cost in extra bytes in the RFC5444 packet and s= ome loss of elegance, but they do allow for some level of compatibility. Really, to make progress, there needs to be some consensus on what level of= compatibility people wish to see defined. My personal recommendation would be that any schema-compression protocol ma= intains backwards compatibility (B), and an appendix is added to any specif= ication detailing optional functionality for forwards compatibility (C), su= ch as packet level RFC5444 TLVs. Rick Taylor P.S> From my reading of RFC5444, a message with no TLVs is perfectly valid = - am I wrong? > -----Original Message----- > From: Christopher Dearlove [mailto:christopher.dearlove@googlemail.com] > Sent: 29 January 2013 08:42 > To: Henning Rogge > Cc: Taylor, Rick; manet@ietf.org > Subject: Re: [manet] RFC5444 schema-based compression V2 > > I've yet to form a definite opinion on this work, but I have one definite > opinion. No breaking compatibility. A minimum requirement is if version i= s > zero, no changes to format. And creating a version one has definite issue= s > that's part of my yet to firm a definite opinion. (As do other solutions = - > encapsulating in TLV, link layer changes.) > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 29 Jan 2013, at 08:14, Henning Rogge > wrote: > > > On 01/28/2013 01:16 PM, Taylor, Rick wrote:>> On 01/28/2013 12:45 PM, > > Taylor, Rick wrote: > >> One potential solution would be to add a NUL message-block (length =3D > >> 0, 4 bytes) to mark the end of the version-0 message-blocks, and > >> the start of the schema-compressed blocks. Not nice, and adds 4 > >> bytes, and it still breaks version-0 parsers, but does allow a > >> mix-and-match approach and general-purpose parsers. > > > > If we are willing to break compatibility, we can easily add a "number o= f > > uncompressed/compressed messages" byte into the message. No need for > > some hack with a message with zero length (which would not be valid > > RFC5444 anyways). > > > >> Agreed, it's not the nicest solution, but it does allow > >> schema-compressed messages to be handled safely by a pre version-0 > >> parser, at a cost of 3 or 4 bytes per schema-compressed > >> message-block. This is very much a work-around but it does allow best > >> compatibility. > > > > I don't think its worth the effort. > > > >> As I said above, I think this is out of scope for RFC5444, some > >> higher level protocol can determine this. > > > > I don't like the idea bootstrapping a lowlevel protocol with a highleve= l > one. > > > > > Does the packetbb security RFC go into this at all? > > > > No. > > > > > > > > On 01/28/2013 02:17 PM, Taylor, Rick wrote: > >> I agree: RFC5444 is for ROUTING protocol messages, not > >> meta-information messages. I would always want to move > >> meta-information out-of-band. > > > > Its still routing information, so I think RFC5444 could be a place for > this. It would also solve the bootstrap problem easily. > > > >> As I see it, either the schema is fixed (as in a final protocol) in > >> which case the schema is documented and widely available, and all > >> participants use the correct final version, or the schema is in flux > >> (as in a prototype or development scenario) in which case > >> participants need a method to check if they have a valid schema for > >> compression/decompression. In this later case I see it as perfectly > >> sensible that the retrieval of the schema is out of band - either the > >> parser does something automated to get and parse the schema, or it > >> just errors with "Mismatched or unknown schema". > > > > Errors like this in a routing protocol are a good way to break your > manet apart. > > > >> Adding the extra specification to cover the transmission of schema > >> meta-information within RFC5444 is just making extra work for > >> yourself. I would much rather see a simple/flexible/lightweight > >> solution such as an optional message-tlv that held a reference to > >> the schema, rather than specifying an RFC5444 compliant schema > >> format. HTTP and FTP a perfectly sensible transport mechanisms, and > >> in a production environment one would not want dynamically updating > >> schemas anyway, so they would be disabled in the parser. > > > > I am not sure "lightweight" and HTTP/FTP mix well in a Manet. > > > > In addition to this including a full URL "where to download the schema" > into a RFC5444 message/packet would be a huge waste of bytes. > > > >>> I think a binary format for the schemas would be a good idea (in > >>> addition to a normal "text form" ?). > >> > >> I think it would make any schema compression RFC longer, harder to > >> ratify and harder to implement. I just don't see the need. Let's > >> reuse ABNF or XML or something (almost) human readable and keep the > >> data out-of-band. > > > > I don't agree here, but we have to see the final structure of a schema > before we can decide on this. > > > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Tue Jan 29 02:40:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4C621F87E1 for ; Tue, 29 Jan 2013 02:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD5oGy97aRbJ for ; Tue, 29 Jan 2013 02:40:39 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C775D21F87E0 for ; Tue, 29 Jan 2013 02:40:36 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U08cE-0002Zk-Ud; Tue, 29 Jan 2013 11:40:34 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U08cE-0003Hz-Ry; Tue, 29 Jan 2013 11:40:34 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Jan 2013 11:40:34 +0100 Message-ID: <5107A719.406@fkie.fraunhofer.de> Date: Tue, 29 Jan 2013 11:40:25 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Taylor, Rick" References: <51014AEB.6070402@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> <510784CA.9000409@fkie.fraunhofer.de> <55d4626e-2265-4ddf-9b85-bbc54dc146bf@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090605050601060700060106" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16584/Tue Jan 29 08:37:32 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c9c66f32f18f586296172d92028f39d6 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression - compatibility X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:40:39 -0000 --------------ms090605050601060700060106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/29/2013 11:37 AM, Taylor, Rick wrote: > P.S> From my reading of RFC5444, a message with no TLVs is perfectly va= lid - am I wrong? See https://tools.ietf.org/html/rfc5444#section-5.2 A minimum RFC5444 message is made from a message-header AND a tlv-block=20 (without TLVs inside). The length field of this message would contain the value 6. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090605050601060700060106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjkxMDQwMzJaMCMGCSqGSIb3DQEJBDEWBBSqN+CfuN12iPOaydiDof3JOI5DSzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAOCmU0uj9MBGrvEHCdeDe4LLQuiE5SPTYn4E+pvqH3kWl //77JDmBF9UVUPXCWtvvnKR8aJJd7gsoG/hnWWZlxAhci+Kmg6SZr1PWLbDxFNyRaMpIoFdu TbUYoQQCgPfUOJoODl49UTDXj3EmXhiR0yy2+G8HEYNmu9WU3pAivSZJdNOYiqALct/um8OC Im0wqC51RfspuPfMvW65gPBMyC4u7/61Y6GGvQV+SRWAVR6tfAjicpoKoff57N3TIkg2EU6S 12uyDi40L6GXpmM3mJhtwO0ixUmM9Jdq4/4zz7vREX/nieoBrwTdY70j6tmKU16ZZ04gzMdL nJoFcvStHwAAAAAAAA== --------------ms090605050601060700060106-- From henning.rogge@fkie.fraunhofer.de Tue Jan 29 06:03:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2021F8691 for ; Tue, 29 Jan 2013 06:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVRTcEHzV4tz for ; Tue, 29 Jan 2013 06:03:00 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D022F21F85A1 for ; Tue, 29 Jan 2013 06:02:59 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0Bm6-0003ok-7i; Tue, 29 Jan 2013 15:02:58 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U0Bm6-0000Jl-4y; Tue, 29 Jan 2013 15:02:58 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Jan 2013 15:02:57 +0100 Message-ID: <5107D68C.5010909@fkie.fraunhofer.de> Date: Tue, 29 Jan 2013 15:02:52 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Bush, Stephen F (GE Global Research)" References: <51014AEB.6070402@fkie.fraunhofer.de> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> <510784CA.9000409@fkie.fraunhofer.de> <55d4626e-2265-4ddf-9b85-bbc54dc146bf@SUCNPTEXC01.COM.AD.UK.DS.CORP> <5107A719.406@fkie.fraunhofer.de> <145E8BB1C9E2B24682B4859763DA5C330FADCA@CINMBCNA03.e2k.ad.ge.com> In-Reply-To: <145E8BB1C9E2B24682B4859763DA5C330FADCA@CINMBCNA03.e2k.ad.ge.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050901010608010302040204" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16585/Tue Jan 29 12:53:11 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 19439b9e9a75a9b48dc1623282e45f76 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression - compatibility X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:03:01 -0000 --------------ms050901010608010302040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Use the link that is below every MANET list to go to the webinterface of = the mailing list: https://www.ietf.org/mailman/listinfo/manet Put your email (the one you are using for this list) into the field=20 besides the "unsubscribe or edit options" button and press the button. Click on the "unsubscribe" button. You should receive an "unsubscribe" mail with a link you have to click=20 on... afterwards you are removed from the list. Henning Rogge On 01/29/2013 02:15 PM, Bush, Stephen F (GE Global Research) wrote: > Can someone please remove me from this list? > > The email server said I was removed, but I'm still receiving messages. > > Thanks, > Stephen Bush > Scientist, GE Global Research > http://www.research.ge.com/~bushsf > Chair IEEE P1906.1 Nano/Molecular Communication http://standards.ieee.o= rg/develop/project/1906.1.html > > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge > Sent: Tuesday, January 29, 2013 5:40 AM > To: Taylor, Rick > Cc: manet@ietf.org > Subject: Re: [manet] RFC5444 schema-based compression - compatibility > > On 01/29/2013 11:37 AM, Taylor, Rick wrote: >> P.S> From my reading of RFC5444, a message with no TLVs is perfectly v= alid - am I wrong? > > See https://tools.ietf.org/html/rfc5444#section-5.2 > > A minimum RFC5444 message is made from a message-header AND a tlv-block= (without TLVs inside). > > The length field of this message would contain the value 6. > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunika= tion, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (= KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050901010608010302040204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMjkxNDAyNTZaMCMGCSqGSIb3DQEJBDEWBBScr00xTkNSNqS5mc/0xoO3lHL1qTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAowbpAgFFdeAeOaLXOOukhBsS/lqENiZAVrVkkOz4mkGd iHDjqGCQzmS6AZ+swsazxoR6xFfMGdLNGZmEIeO8X3k+JlO2RDacukhfxUDkEdzFEEbNA+rR l5si/hUzjrF/d1+FnQ9o7GUuLtjDZnpSeyWjAu7GkBLbwm6aF2ZQuUiJSFJw3jdavgu47BkY iIBrJM6IKb7gde9FZWP9A2BxqO1rIyEAgp5dkU3utF/SXo9TQE7LZtDttLZ/JT9KgbBzqlqi 7rYl/97visVTCxPGJFUYmdleiMby1Ok3XGFblaBu8kTHTdJ6YdxAr7ei8Zm3OpzGooYdiprH RbaXgt5vuQAAAAAAAA== --------------ms050901010608010302040204-- From jpmacker@gmail.com Tue Jan 29 10:11:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD26D21F8AB2 for ; Tue, 29 Jan 2013 10:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN225Fw7VXUg for ; Tue, 29 Jan 2013 10:11:24 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32621F8AAD for ; Tue, 29 Jan 2013 10:11:23 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so515940lab.23 for ; Tue, 29 Jan 2013 10:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2ltuLu6pM2e0la9WnELI9oGY9F1V39qChm5eSkioiT0=; b=THnRk4HlA1cmCziXGx1N3ujeQ4VjlNIavZEe4WQtWmuIqE9bJBm2jaUAxmvpdJM6Ju fmHRX7WxelfrCCS2K0FwaG5A0GyNFj0cZooWcKtTZXiZTcUfinu8fOSfH+OpfH/mMdI7 9gIdm3nGiJnZcgltEGs4g93wV1La0dYMEp20zzy4w2sCPjVgsy5TFhI7hrjics+LAtsF BsdqppvW1vsbZPHYaVYq9l5AkpKTa2GKISxGaFWwfFwGhQ4Z0nq8sgVfHUgDhoDQQdbu 6Z7cmtx5SYYsNUp6obvNhjvY88Nv7hE+/yT2dgLzIT/q0p36xTB1k6vpJk8vmxX970k+ gKxg== MIME-Version: 1.0 X-Received: by 10.112.43.99 with SMTP id v3mr823003lbl.103.1359483082602; Tue, 29 Jan 2013 10:11:22 -0800 (PST) Received: by 10.112.148.102 with HTTP; Tue, 29 Jan 2013 10:11:22 -0800 (PST) In-Reply-To: <32A3BE87-988D-457F-8526-93BD712D1A7D@gmail.com> References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> <510784CA.9000409@fkie.fraunhofer.de> <32A3BE87-988D-457F-8526-93BD712D1A7D@gmail.com> Date: Tue, 29 Jan 2013 13:11:22 -0500 Message-ID: From: Joseph Macker To: Christopher Dearlove Content-Type: multipart/alternative; boundary=485b390f7b5237793c04d47152bb Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:11:25 -0000 --485b390f7b5237793c04d47152bb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Definitely check the ROHC community documentation for any relevant lessons learned. On Tue, Jan 29, 2013 at 3:42 AM, Christopher Dearlove < christopher.dearlove@googlemail.com> wrote: > I've yet to form a definite opinion on this work, but I have one definite > opinion. No breaking compatibility. A minimum requirement is if version i= s > zero, no changes to format. And creating a version one has definite issue= s > that's part of my yet to firm a definite opinion. (As do other solutions = - > encapsulating in TLV, link layer changes.) > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 29 Jan 2013, at 08:14, Henning Rogge > wrote: > > > On 01/28/2013 01:16 PM, Taylor, Rick wrote:>> On 01/28/2013 12:45 PM, > > Taylor, Rick wrote: > >> One potential solution would be to add a NUL message-block (length =3D > >> 0, 4 bytes) to mark the end of the version-0 message-blocks, and > >> the start of the schema-compressed blocks. Not nice, and adds 4 > >> bytes, and it still breaks version-0 parsers, but does allow a > >> mix-and-match approach and general-purpose parsers. > > > > If we are willing to break compatibility, we can easily add a "number o= f > > uncompressed/compressed messages" byte into the message. No need for > > some hack with a message with zero length (which would not be valid > > RFC5444 anyways). > > > >> Agreed, it's not the nicest solution, but it does allow > >> schema-compressed messages to be handled safely by a pre version-0 > >> parser, at a cost of 3 or 4 bytes per schema-compressed > >> message-block. This is very much a work-around but it does allow best > >> compatibility. > > > > I don't think its worth the effort. > > > >> As I said above, I think this is out of scope for RFC5444, some > >> higher level protocol can determine this. > > > > I don't like the idea bootstrapping a lowlevel protocol with a highleve= l > one. > > > > > Does the packetbb security RFC go into this at all? > > > > No. > > > > > > > > On 01/28/2013 02:17 PM, Taylor, Rick wrote: > >> I agree: RFC5444 is for ROUTING protocol messages, not > >> meta-information messages. I would always want to move > >> meta-information out-of-band. > > > > Its still routing information, so I think RFC5444 could be a place for > this. It would also solve the bootstrap problem easily. > > > >> As I see it, either the schema is fixed (as in a final protocol) in > >> which case the schema is documented and widely available, and all > >> participants use the correct final version, or the schema is in flux > >> (as in a prototype or development scenario) in which case > >> participants need a method to check if they have a valid schema for > >> compression/decompression. In this later case I see it as perfectly > >> sensible that the retrieval of the schema is out of band - either the > >> parser does something automated to get and parse the schema, or it > >> just errors with "Mismatched or unknown schema". > > > > Errors like this in a routing protocol are a good way to break your > manet apart. > > > >> Adding the extra specification to cover the transmission of schema > >> meta-information within RFC5444 is just making extra work for > >> yourself. I would much rather see a simple/flexible/lightweight > >> solution such as an optional message-tlv that held a reference to > >> the schema, rather than specifying an RFC5444 compliant schema > >> format. HTTP and FTP a perfectly sensible transport mechanisms, and > >> in a production environment one would not want dynamically updating > >> schemas anyway, so they would be disabled in the parser. > > > > I am not sure "lightweight" and HTTP/FTP mix well in a Manet. > > > > In addition to this including a full URL "where to download the schema" > into a RFC5444 message/packet would be a huge waste of bytes. > > > >>> I think a binary format for the schemas would be a good idea (in > >>> addition to a normal "text form" ?). > >> > >> I think it would make any schema compression RFC longer, harder to > >> ratify and harder to implement. I just don't see the need. Let's > >> reuse ABNF or XML or something (almost) human readable and keep the > >> data out-of-band. > > > > I don't agree here, but we have to see the final structure of a schema > before we can decide on this. > > > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --485b390f7b5237793c04d47152bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Definitely check the ROHC community documentation for any = relevant lessons learned.


On Tue, Jan 29, 2013 at 3:42 AM, Christopher Dearlove= <christopher.dearlove@googlemail.com> wro= te:
I've yet to form a definite opinion on t= his work, but I have one definite opinion. No breaking compatibility. A min= imum requirement is if version is zero, no changes to format. And creating = a version one has definite issues that's part of my yet to firm a defin= ite opinion. (As do other solutions - encapsulating in TLV, link layer chan= ges.)

--
Christopher Dearlove
christopher.dearlove@gmai= l.com (iPhone)
chris@mnemosyne.demon.co.uk<= /a> (home)

On 29 Jan 2013, at 08:14, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:

> On 01/28/2013 01:16 PM, Taylor, Rick wrote:>> On 01/28/2013 12:4= 5 PM,
> Taylor, Rick wrote:
>> One potential solution would be to add a NUL message-block (length= =3D
>> 0, 4 bytes) to mark the end of the version-0 message-blocks, and >> the start of the schema-compressed blocks. =A0Not nice, and adds 4=
>> bytes, and it still breaks version-0 parsers, but does allow a
>> mix-and-match approach and general-purpose parsers.
>
> If we are willing to break compatibility, we can easily add a "nu= mber of
> uncompressed/compressed messages" byte into the message. No need = for
> some hack with a message with zero length (which would not be valid > RFC5444 anyways).
>
>> Agreed, it's not the nicest solution, but it does allow
>> schema-compressed messages to be handled safely by a pre version-0=
>> parser, at a cost of 3 or 4 bytes per schema-compressed
>> message-block. This is very much a work-around but it does allow b= est
>> compatibility.
>
> I don't think its worth the effort.
>
>> As I said above, I think this is out of scope for RFC5444, some >> higher level protocol can determine this.
>
> I don't like the idea bootstrapping a lowlevel protocol with a hig= hlevel one.
>
> > Does the packetbb security RFC go into this at all?
>
> No.
>
>
>
> On 01/28/2013 02:17 PM, Taylor, Rick wrote:
>> I agree: RFC5444 is for ROUTING protocol messages, not
>> meta-information messages. =A0I would always want to move
>> meta-information out-of-band.
>
> Its still routing information, so I think RFC5444 could be a place for= this. It would also solve the bootstrap problem easily.
>
>> As I see it, either the schema is fixed (as in a final protocol) i= n
>> which case the schema is documented and widely available, and all<= br> >> participants use the correct final version, or the schema is in fl= ux
>> (as in a prototype or development scenario) in which case
>> participants need a method to check if they have a valid schema fo= r
>> compression/decompression. =A0In this later case I see it as perfe= ctly
>> sensible that the retrieval of the schema is out of band - either = the
>> parser does something automated to get and parse the schema, or it=
>> just errors with "Mismatched or unknown schema".
>
> Errors like this in a routing protocol are a good way to break your ma= net apart.
>
>> Adding the extra specification to cover the transmission of schema=
>> meta-information within RFC5444 is just making extra work for
>> yourself. =A0I would much rather see a simple/flexible/lightweight=
>> solution such as an optional message-tlv that held a reference to<= br> >> the schema, rather than specifying an RFC5444 compliant schema
>> format. HTTP and FTP a perfectly sensible transport mechanisms, an= d
>> in a production environment one would not want dynamically updatin= g
>> schemas anyway, so they would be disabled in the parser.
>
> I am not sure "lightweight" and HTTP/FTP mix well in a Manet= .
>
> In addition to this including a full URL "where to download the s= chema" into a RFC5444 message/packet would be a huge waste of bytes. >
>>> I think a binary format for the schemas would be a good idea (= in
>>> addition to a normal "text form" ?).
>>
>> I think it would make any schema compression RFC longer, harder to=
>> ratify and harder to implement. =A0I just don't see the need. = =A0Let's
>> reuse ABNF or XML or something (almost) human readable and keep th= e
>> data out-of-band.
>
> I don't agree here, but we have to see the final structure of a sc= hema before we can decide on this.
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
> mailto:henning.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
> __________________= _____________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--485b390f7b5237793c04d47152bb-- From henning.rogge@fkie.fraunhofer.de Tue Jan 29 23:37:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2F721F8477 for ; Tue, 29 Jan 2013 23:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7dFNSdv0jeh for ; Tue, 29 Jan 2013 23:37:16 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEB121F8499 for ; Tue, 29 Jan 2013 23:37:15 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0SEM-0002Sz-53; Wed, 30 Jan 2013 08:37:14 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U0SEM-0004iN-2K; Wed, 30 Jan 2013 08:37:14 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 Jan 2013 08:37:13 +0100 Message-ID: <5108CDA2.7010007@fkie.fraunhofer.de> Date: Wed, 30 Jan 2013 08:37:06 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joseph Macker References: <51014AEB.6070402@fkie.fraunhofer.de> <51023F7E.9020103@fkie.fraunhofer.de> <5E9ABF5A-1B72-4E4F-AE22-A9B9FC6D5371@inf-net.nl> <4C30C0A1-738B-4952-A5D3-208813550DCE@inf-net.nl> <5102A2D3.9050303@fkie.fraunhofer.de> <333F1BEC-93B6-4E62-B6BA-6CFD4401231A@inf-net.nl> <8ae47df6-9690-4241-9e4d-c0a337fbf314@SUCNPTEXC01.COM.AD.UK.DS.CORP> <510784CA.9000409@fkie.fraunhofer.de> <32A3BE87-988D-457F-8526-93BD712D1A7D@gmail.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050100020003040102010201" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16591/Wed Jan 30 06:41:12 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 44205366898805df1de72924aa95b600 Cc: "manet@ietf.org" Subject: Re: [manet] RFC5444 schema-based compression V2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 07:37:17 -0000 --------------ms050100020003040102010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/29/2013 07:11 PM, Joseph Macker wrote: > Definitely check the ROHC community documentation for any relevant > lessons learned. Do you have a special document in mind (maybe with an URL) ? I have=20 worked with ROHC in the past here at the institute, but I don't remember = a 'community documentation'. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050100020003040102010201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMzAwNzM3MTFaMCMGCSqGSIb3DQEJBDEWBBRRfyZALhdew90waMAL91spDQCHUTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEATpll8Cn961A9vRgQEHeT2a7xj1Dm/KR5XOp9VUXyI7Tf eahhDExiknR+75Zm4QhTV06HbhD+Hr19HaZh62mZhYMqAghYrBzER8Ab3zte0+3Ra81mEtWf Xz4yZ38F3AGnElFNsRECnALxQMwU04gA69y0akcigpzEWsR1Z8+NHtlOO/V6AHnEfXcAFI79 JfTVhDsapMJY44+L2QLZT8RVaXIPGko1CP71d6HUVguDXlAe+KK9FvvQMmCiUqaVY8ItpHy6 7oqF/LyV0VADAdNAD6TTEJ7jNxOUzqyzsi0tn/bdDE2W+q61I8NHbUmMCzh/fVdVXPN4sipQ 1fGCR++rJAAAAAAAAA== --------------ms050100020003040102010201-- From henning.rogge@fkie.fraunhofer.de Wed Jan 30 00:03:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9C21F866F for ; Wed, 30 Jan 2013 00:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPyKgwFC6u55 for ; Wed, 30 Jan 2013 00:03:15 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 27D1721F8AE6 for ; Wed, 30 Jan 2013 00:03:15 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0SdW-0002PO-0n for manet@ietf.org; Wed, 30 Jan 2013 09:03:14 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U0SdV-0005Pb-UP for manet@ietf.org; Wed, 30 Jan 2013 09:03:13 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 Jan 2013 09:03:13 +0100 Message-ID: <5108D3C0.2000805@fkie.fraunhofer.de> Date: Wed, 30 Jan 2013 09:03:12 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000009020209060101090401" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16591/Wed Jan 30 06:41:12 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d035fb019c3cbd4d1cef885229a6404a Subject: [manet] Thoughts about schema-based address compression X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 08:03:16 -0000 --------------ms000009020209060101090401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I worked a bit on adding address compression to the schema-based system=20 we are discussing at the moment. The idea is simple: - A schema can contain up to 14 addresses (up to 16 bytes) in addition=20 to information about the message header and TLVs. - Every address block that use head or tail compression can refer to one = of these addresses instead of explicitly including the prefix in the=20 bytestream. Both head and tail compression of addresses call for a 1 byte length=20 field to define the split between header-, tail- and mid-parts. Because of the limited address length of 16 bytes these length fields=20 only contain numbers between 1 and 15. My idea is to reuse the "free" four bits of the length field to allow=20 the address block to refer to one of the stored addresses or the=20 originator of the message. I think this could be a major help for IPv6 MANETs. I am still thinking about how to include this idea for the originator=20 address. Example Schema: --------------- =2E.. Address 1: 10.0.0.0 Uncompressed address block: ---------------------------- 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.), = no prefix # 03 # =3D ahashead 80 # 03 0A 00 00 # * 01 02 03 Example for compressed address blocks: -------------------------------------- 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.), = no prefix # 03 # =3D ahashead 80 # , refer to schema address 1 for head bytes 13 # * 01 02 03 Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000009020209060101090401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMzAwODAzMTJaMCMGCSqGSIb3DQEJBDEWBBQnPCD2oz8bZoqYes5zP9u/N/ydEDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAH4TPeh84EJvFjlP6iYDCqcD1M0fLdpU5W/OhHRmV7UDj F5NgquZDujv8MjFIUp/8bxgVZKa5hloyHoNFYx358PI5nfV9LDlvpWNIhtempmA0Aze0oJeD JBnCZ0Ow+gGFgCuPRglj9OPvRShoenY8BowHdNnUBlFAKb8V+EhyN+cMoer7tKR3tyWFi1w1 cGowaGTiqaUKKFUbdNyjlfX/P4o4HxG902yNyXd66oNGIQcUhzcxuVmr/p/Q4F/DRkZrToDM BPhOQQAaWr/y0sNZGUmoh+E5qSrU0lAsHcejWNFb+pr8g62SsS/FSDZ2zDQhplAeqM3FTxqp 9CUCEjfKTQAAAAAAAA== --------------ms000009020209060101090401-- From rick.taylor@cassidian.com Wed Jan 30 02:01:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF921F87AA for ; Wed, 30 Jan 2013 02:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MejC0hR+zFIB for ; Wed, 30 Jan 2013 02:01:06 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 467A721F87C5 for ; Wed, 30 Jan 2013 02:01:05 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 30 Jan 2013 11:01:03 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 30 Jan 2013 11:01:02 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 11:01:02 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 11:01:02 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 10:01:02 +0000 From: "Taylor, Rick" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Thoughts about schema-based address compression Thread-Index: AQHN/sBiJ4MiGtpHKkSV0unDhE/CDZhhn/wg Date: Wed, 30 Jan 2013 10:01:01 +0000 Message-ID: References: <9237ee3b-b207-4abb-b89e-c550f925a28f@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <9237ee3b-b207-4abb-b89e-c550f925a28f@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2013 10:01:02.0529 (UTC) FILETIME=[B617FB10:01CDFED0] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19598.006 X-TM-AS-Result: No--15.932200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Thoughts about schema-based address compression X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:01:08 -0000 It sounds elegant, but I have concerns over the maximum number of addresses= per address-block. But I suppose that if I have more than 14 addresses wi= th a common prefix I can just add more address blocks with identical header= information. Given the restrictions on address length and number of addresses per block,= it would be nice if the schema could specify that the address blocks of a = schema-compressed message were in uncompressed (RFC5444) format, allowing t= he 8bit prefix-length and address-count. I agree that this is a corner cas= e, but people do try to stuff all kinds of data into 'addresses' when they = first look at RFC5444 - I can imagine someone using a SHA1 hash as an addre= ss - terrible compression, but legitimate in RFC5444. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 30 January 2013 08:03 > To: manet@ietf.org > Subject: [manet] Thoughts about schema-based address compression > > I worked a bit on adding address compression to the schema-based system > we are discussing at the moment. > > The idea is simple: > > - A schema can contain up to 14 addresses (up to 16 bytes) in addition > to information about the message header and TLVs. > > - Every address block that use head or tail compression can refer to one > of these addresses instead of explicitly including the prefix in the > bytestream. > > Both head and tail compression of addresses call for a 1 byte length > field to define the split between header-, tail- and mid-parts. > > Because of the limited address length of 16 bytes these length fields > only contain numbers between 1 and 15. > > My idea is to reuse the "free" four bits of the length field to allow > the address block to refer to one of the stored addresses or the > originator of the message. > > I think this could be a major help for IPv6 MANETs. > > I am still thinking about how to include this idea for the originator > address. > > > > Example Schema: > --------------- > ... > Address 1: 10.0.0.0 > > > > Uncompressed address block: > ---------------------------- > 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.), > no prefix > > # > 03 > > # =3D ahashead > 80 > > # > 03 0A 00 00 > > # * > 01 02 03 > > > Example for compressed address blocks: > -------------------------------------- > > 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.), > no prefix > > # > 03 > > # =3D ahashead > 80 > > # , refer to schema address 1 for head bytes > 13 > > # * > 01 02 03 > > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From henning.rogge@fkie.fraunhofer.de Wed Jan 30 06:20:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D7221F8B35 for ; Wed, 30 Jan 2013 06:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFjvdrI+qnZD for ; Wed, 30 Jan 2013 06:20:42 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 53DF821F8B13 for ; Wed, 30 Jan 2013 06:20:42 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0YWl-0002KV-S6; Wed, 30 Jan 2013 15:20:39 +0100 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U0YWl-0007VQ-PP; Wed, 30 Jan 2013 15:20:39 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 Jan 2013 15:20:39 +0100 Message-ID: <51092C32.5010304@fkie.fraunhofer.de> Date: Wed, 30 Jan 2013 15:20:34 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Taylor, Rick" References: <9237ee3b-b207-4abb-b89e-c550f925a28f@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090905020508010705050902" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16592/Wed Jan 30 12:41:25 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Cc: "manet@ietf.org" Subject: Re: [manet] Thoughts about schema-based address compression X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:20:43 -0000 --------------ms090905020508010705050902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01/30/2013 11:01 AM, Taylor, Rick wrote: > It sounds elegant, but I have concerns over the maximum number of > addresses per address-block. But I suppose that if I have more than > 14 addresses with a common prefix I can just add more address blocks > with identical header information. Its more a limit of different "pre-stored" prefixes for the whole message. Multiple address blocks can use the same indexed schema-prefix of course. > Given the restrictions on address length and number of addresses per > block, it would be nice if the schema could specify that the address > blocks of a schema-compressed message were in uncompressed (RFC5444) > format, allowing the 8bit prefix-length and address-count. I agree > that this is a corner case, but people do try to stuff all kinds of > data into 'addresses' when they first look at RFC5444 - I can > imagine someone using a SHA1 hash as an address - terrible > compression, but legitimate in RFC5444. The extension I suggested is full backward compatible to RFC5444. if you set the length of your head/tail to 1-15, the compressor will=20 just assume the head/tail will follow in the bytestream. If you set a=20 number greater than 0 in the first four bits, you say "instead of=20 explicitly writing the head/tail, just take it from schema address X". Have to work out a text that is easier to understand. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090905020508010705050902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMzAxNDIwMzdaMCMGCSqGSIb3DQEJBDEWBBRXrLZyKPj7OFf77Ky7EFIDC/DwpTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAv5yyqJ1RbASzRoNyivgy7arambeqzPkaaUMkXa/n6wjc TzaiLSAiejuB8tPWoIy/1ZjTkyxQFeKIHTTzWsYuFr3ZLy6cvnhtyWDeHJjQP3mKvIMkJ1uS JWbYWObaaLHaK7voln2soq5iaTWhLpid85LRFw8EUc3Hjj2fhkS/YUvDJ6XjKj+iDjFgJGwq JHfb+0eQynvZ/OiDnuAAbTs5n0SLqPAWry7586QfstjkON/kHNuOCLHVHIu3L47u73bG6PrD tzix4IjbR1hxPBIOVTEyvfhoxS81s1MCqmRb51vtCU1aNrUhk4DB2nLGypo56QOREVouHc9a 4Od7LRFKmAAAAAAAAA== --------------ms090905020508010705050902-- From ietf@thomasclausen.org Wed Jan 30 07:21:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3770F21F88CC for ; Wed, 30 Jan 2013 07:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBajAvi-6LMX for ; Wed, 30 Jan 2013 07:21:28 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EF59A21F88CA for ; Wed, 30 Jan 2013 07:21:27 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8514DA6977 for ; Wed, 30 Jan 2013 07:21:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2BF981BD3938; Wed, 30 Jan 2013 07:21:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.130.255.67] (unknown [37.160.18.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 598B71BD392C; Wed, 30 Jan 2013 07:21:20 -0800 (PST) References: <9237ee3b-b207-4abb-b89e-c550f925a28f@SUCNPTEXC01.COM.AD.UK.DS.CORP> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B143) From: Thomas Heide Clausen Date: Wed, 30 Jan 2013 16:21:16 +0100 To: "Taylor, Rick" Cc: "manet@ietf.org" Subject: Re: [manet] Thoughts about schema-based address compression X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 15:21:29 -0000 I have deployments of OLSRv2 right now where (just checked this morning) I s= ee messages with well more than 14 IPv6 addresses (max I saw was 29) with th= e same TLV.=20 Just one datapoint.=20 --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 30 janv. 2013, at 11:01, "Taylor, Rick" wrote= : > It sounds elegant, but I have concerns over the maximum number of addresse= s per address-block. But I suppose that if I have more than 14 addresses wi= th a common prefix I can just add more address blocks with identical header i= nformation. >=20 > Given the restrictions on address length and number of addresses per block= , it would be nice if the schema could specify that the address blocks of a s= chema-compressed message were in uncompressed (RFC5444) format, allowing the= 8bit prefix-length and address-count. I agree that this is a corner case, b= ut people do try to stuff all kinds of data into 'addresses' when they first= look at RFC5444 - I can imagine someone using a SHA1 hash as an address - t= errible compression, but legitimate in RFC5444. >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= >> Henning Rogge >> Sent: 30 January 2013 08:03 >> To: manet@ietf.org >> Subject: [manet] Thoughts about schema-based address compression >>=20 >> I worked a bit on adding address compression to the schema-based system >> we are discussing at the moment. >>=20 >> The idea is simple: >>=20 >> - A schema can contain up to 14 addresses (up to 16 bytes) in addition >> to information about the message header and TLVs. >>=20 >> - Every address block that use head or tail compression can refer to one >> of these addresses instead of explicitly including the prefix in the >> bytestream. >>=20 >> Both head and tail compression of addresses call for a 1 byte length >> field to define the split between header-, tail- and mid-parts. >>=20 >> Because of the limited address length of 16 bytes these length fields >> only contain numbers between 1 and 15. >>=20 >> My idea is to reuse the "free" four bits of the length field to allow >> the address block to refer to one of the stored addresses or the >> originator of the message. >>=20 >> I think this could be a major help for IPv6 MANETs. >>=20 >> I am still thinking about how to include this idea for the originator >> address. >>=20 >>=20 >>=20 >> Example Schema: >> --------------- >> ... >> Address 1: 10.0.0.0 >>=20 >>=20 >>=20 >> Uncompressed address block: >> ---------------------------- >> 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.), >> no prefix >>=20 >> # >> 03 >>=20 >> # =3D ahashead >> 80 >>=20 >> # >> 03 0A 00 00 >>=20 >> # * >> 01 02 03 >>=20 >>=20 >> Example for compressed address blocks: >> -------------------------------------- >>=20 >> 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.), >> no prefix >>=20 >> # >> 03 >>=20 >> # =3D ahashead >> 80 >>=20 >> # , refer to schema address 1 for head bytes >> 13 >>=20 >> # * >> 01 02 03 >>=20 >>=20 >>=20 >> Henning Rogge >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > The information contained within this e-mail and any files attached to thi= s e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and t= herefore if you wish to disclose the information contained within this e-mai= l or attached files, please contact the sender prior to any such disclosure.= If you are not the intended recipient, any disclosure, copying or distribut= ion is prohibited. Please also contact the sender and inform them of the err= or and delete the e-mail, including any attached files from your system. Cas= sidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkern= ew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Jan 30 09:58:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4B21F872D for ; Wed, 30 Jan 2013 09:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCc4HNDeQbHX for ; Wed, 30 Jan 2013 09:58:26 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1DA21F86B1 for ; Wed, 30 Jan 2013 09:58:26 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id 16so1547901iea.22 for ; Wed, 30 Jan 2013 09:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=3ayTYFvq+8n7SCbsXh+gqa2po/G16f4f8YL7ei3alFQ=; b=hlKatm3d3xjlmwdU5uWKJyYb5FxJHK5KNzbOsz9NHKSqFsQTmhc1MSGWkFFMF9do0a D5hbsbcQEwPaQ316ekwTtVzMR1mfBp66/csBpHReSIZqVnrZR++tWrMqaOxuBPdzqxui tULnJEhxlbTuQWDE2xemkruRxtDspIoGGGmIOp9TjOksVK1uiPDXzcXXUWYi/up4PBzS YDkKPsEt+fd0giZ5i/trAvPEzak2Q6bAYkadHi0oazbNx8rKd3kUlHq5qinfIZYbXx42 4Q41R/b686lZL1SCkoyAdk02Yuo4uBtuHHxlyK261/Mk8vkgYARR/o0tVipO8BiMtrjr Z2+w== X-Received: by 10.50.189.233 with SMTP id gl9mr3979422igc.81.1359568705887; Wed, 30 Jan 2013 09:58:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.7 with HTTP; Wed, 30 Jan 2013 09:58:05 -0800 (PST) In-Reply-To: References: <9237ee3b-b207-4abb-b89e-c550f925a28f@SUCNPTEXC01.COM.AD.UK.DS.CORP> From: Henning Rogge Date: Wed, 30 Jan 2013 18:58:05 +0100 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Thoughts about schema-based address compression X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:58:27 -0000 Maybe just to add another explanation... why a maximum of 14 schema-stored heads/tails? Because we have 4 free bits in the . Why not 15 or 16? The 0000 is reserved for the default case where the is stored in the message itself. And I would like to use the 1111 to make the decompressor take the from the of the message. Henning Rogge On Wed, Jan 30, 2013 at 4:21 PM, Thomas Heide Clausen wrote: > I have deployments of OLSRv2 right now where (just checked this morning) = I see messages with well more than 14 IPv6 addresses (max I saw was 29) wit= h the same TLV. > > Just one datapoint. > > -- > Thomas Heide Clausen > http://www.thomasclausen.org > > "Today's scientists have substituted mathematics for > experiments, and they wander off through equation > after equation, and eventually build a structure > which has no relation to reality." > - Nikola Tesla, > Modern Mechanics and Inventions, July, 1934 > > On 30 janv. 2013, at 11:01, "Taylor, Rick" wr= ote: > >> It sounds elegant, but I have concerns over the maximum number of addres= ses per address-block. But I suppose that if I have more than 14 addresses= with a common prefix I can just add more address blocks with identical hea= der information. >> >> Given the restrictions on address length and number of addresses per blo= ck, it would be nice if the schema could specify that the address blocks of= a schema-compressed message were in uncompressed (RFC5444) format, allowin= g the 8bit prefix-length and address-count. I agree that this is a corner = case, but people do try to stuff all kinds of data into 'addresses' when th= ey first look at RFC5444 - I can imagine someone using a SHA1 hash as an ad= dress - terrible compression, but legitimate in RFC5444. >> >> Rick Taylor >> >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of >>> Henning Rogge >>> Sent: 30 January 2013 08:03 >>> To: manet@ietf.org >>> Subject: [manet] Thoughts about schema-based address compression >>> >>> I worked a bit on adding address compression to the schema-based system >>> we are discussing at the moment. >>> >>> The idea is simple: >>> >>> - A schema can contain up to 14 addresses (up to 16 bytes) in addition >>> to information about the message header and TLVs. >>> >>> - Every address block that use head or tail compression can refer to on= e >>> of these addresses instead of explicitly including the prefix in the >>> bytestream. >>> >>> Both head and tail compression of addresses call for a 1 byte length >>> field to define the split between header-, tail- and mid-parts. >>> >>> Because of the limited address length of 16 bytes these length fields >>> only contain numbers between 1 and 15. >>> >>> My idea is to reuse the "free" four bits of the length field to allow >>> the address block to refer to one of the stored addresses or the >>> originator of the message. >>> >>> I think this could be a major help for IPv6 MANETs. >>> >>> I am still thinking about how to include this idea for the originator >>> address. >>> >>> >>> >>> Example Schema: >>> --------------- >>> ... >>> Address 1: 10.0.0.0 >>> >>> >>> >>> Uncompressed address block: >>> ---------------------------- >>> 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.)= , >>> no prefix >>> >>> # >>> 03 >>> >>> # =3D ahashead >>> 80 >>> >>> # >>> 03 0A 00 00 >>> >>> # * >>> 01 02 03 >>> >>> >>> Example for compressed address blocks: >>> -------------------------------------- >>> >>> 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.)= , >>> no prefix >>> >>> # >>> 03 >>> >>> # =3D ahashead >>> 80 >>> >>> # , refer to schema address 1 for head bytes >>> 13 >>> >>> # * >>> 01 02 03 >>> >>> >>> >>> Henning Rogge >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> The information contained within this e-mail and any files attached to t= his e-mail is private and in addition may include commercially sensitive in= formation. The contents of this e-mail are for the intended recipient only = and therefore if you wish to disclose the information contained within this= e-mail or attached files, please contact the sender prior to any such disc= losure. If you are not the intended recipient, any disclosure, copying or d= istribution is prohibited. Please also contact the sender and inform them o= f the error and delete the e-mail, including any attached files from your s= ystem. Cassidian Limited, Registered Office : Quadrant House, Celtic Spring= s, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.= com >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan