From manet-bounces@ietf.org Fri Jun 01 09:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6tP-0007HY-6q; Fri, 01 Jun 2007 09:10:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hu6tN-0007HS-Bf for manet-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 09:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6tN-0007HJ-21 for manet@ietf.org; Fri, 01 Jun 2007 09:10:09 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hu6tL-00025y-Iy for manet@ietf.org; Fri, 01 Jun 2007 09:10:09 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1180703406!21842371!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 9972 invoked from network); 1 Jun 2007 13:10:06 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-6.tower-128.messagelabs.com with SMTP; 1 Jun 2007 13:10:06 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l51DA5I7024178 for ; Fri, 1 Jun 2007 06:10:05 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l51DA4GE011421 for ; Fri, 1 Jun 2007 08:10:05 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l51DA3oB011323 for ; Fri, 1 Jun 2007 08:10:03 -0500 (CDT) Message-ID: <46601AA5.2050706@gmail.com> Date: Fri, 01 Jun 2007 15:09:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-0, 30/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [manet] Comments on DYMO X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, some of these comments were raised previously I believe. DYMO is in draft-ietf-manet-dymo-09.txt > Most DYMO messages are sent with the IP destination address set to > the link-local multicast address LL MANET ROUTERS unless otherwise > stated. Unicast DYMO messages specified in this document are sent > with the IP destination set to the Route.NextHopAddress of the route > to the TargetNode. RREQs are specified to be sent to a LL multicast address, but nodes are not required to join that group - they should, and probably better with MLD and IGMP. > When a node originates a data packet and does not have a forwarding > route to the IP.DestinationAddress, it sends a RREQ (described in > Section 5.3.1) to discover a route to the particular destination > (TargetNode). Apparently the application must run on the router that initiates the RREQ. Ie it is not possible to have an LFN behind an MR because MR doesn't know when to send the RREQ. With NEMO moving networks the LFN (Local Fixed Node) is a vanilla stack host not doing any mobility nor much dynamic routing. Another question that comes to mind is how does a DYMO router discover its neighbor routers? Apparently DYMO doesn't specify anything for this. I think ND rfc2461 should be used for that purpose. > The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) > for all messages specified in this document. 1? Then the DYMO messages are discarded when crossing another router? Or is the entire MANET a single subnet? > IP.DestinationAddress The IP address of the packet destination. For > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For RREP > the IP.DestinationAddress is set to the NextHopAddress toward the > TargetNode. So all MANET routers must join the LL MANET routers address - is this specified? > MsgHdr.HopCnt The number of hops this message has traversed. Why is there a need of this field when the Hop Limit in the IP header does the same thing? > AddBlk.TargetNode.Address The IP address of the message TargetNode. > In a RREQ the TargetNode is the destination for which a forwarding > route does not exist and route discovery is being performed. In a > RREP the target node is the RREQ OrigNode. The TargetNode address is > the first address in the routing message. Why is the TargetNode address necessary in the RREP when the IP dst field contains the same thing? > AddBlk.OrigNode.Address The IP address of the OrigNode. This address > is in an address block and not in the message header to allow for > address compression and additional AddTLVs. This address is the > second address in the message for RREQ. Why is this here when the src field has it too? > The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ > TargetNode, so that the RREQ TargetNode receives routing information > on how to reach the RREQ OrigNode. But a gratuitous message is sent without receiving any message (no RREQ received), so how does the intermediate node know the RREQ TargetNode? > Before processing a RM, a node checks the IP.Destination to ensure > that it is a link-local packet. Only 'link-local'? We know (by this spec) that the dst address can be a ll multicast address or a unicast address. If the unicast address can only have a ll scope (fe80) then the entire MANET can only be a single subnet? > 5.7. Advertising Network Addresses > > Any node can advertise a network address by using a PREFIX_LENGTH TLV > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising > node) within the advertised prefix SHOULD NOT participate in the DYMO > protocol directly and these nodes MUST be reachable by forwarding > packets to the node advertising connectivity. Nodes other than the > advertising node that do participate in DYMO must forward the DYMO > control packets to the advertising node. For example, A.B.C.1 with a > prefix length of 24 indicates all nodes with the matching A.B.C.X > are reachable through the node with address A.B.C.1. Ok, but does MANET Router send Router Advertisements? > 8. Security Considerations > > Currently, DYMO does not specify any special security measures. > Routing protocols, however, are prime targets for impersonation > attacks. In networks where the node membership is not known, it is > difficult to determine the occurrence of impersonation attacks, and > security prevention techniques are difficult at best. However, when > the network membership is known and there is a danger of such attacks What is 'node membership'? > While DYMO does not place restrictions on the authentication > mechanism used for this purpose, IPsec Authentication Message (AH) is > an appropriate choice for cases where the nodes share an appropriate > security association that enables the use of AH. How about recommending IPsec ESP too? > If the mobile nodes in the ad hoc network have pre-established > security associations, the purposes for which the security > associations are created should include that of authorizing the > processing of DYMO control packets. Given this understanding, the > mobile nodes should be able to use the same authentication mechanisms > based on their IP addresses as they would have used otherwise. And if the mobile nodes in the ad hoc network _don't_ have pre-established security associations? This case is very important for MANEMO types of deployments where NEMO moving networks come and go. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jun 02 06:15:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQdh-0001n7-7X; Sat, 02 Jun 2007 06:15:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HuQdf-0001mr-HZ for manet-confirm+ok@megatron.ietf.org; Sat, 02 Jun 2007 06:15:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQde-0001md-QF for manet@ietf.org; Sat, 02 Jun 2007 06:15:14 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuQde-0005TJ-5V for manet@ietf.org; Sat, 02 Jun 2007 06:15:14 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1157629ugc for ; Sat, 02 Jun 2007 03:15:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YSjg0DfMMiTPptQ8+2/4l3RK8UXCUhgt6irwiF56JVV0eGVcZdMeqJefovrsGQJd9D1WpeEv0n70mftg89zeZKtk8Ezcq/a2CWc3AfSPcjl888LlNcV0I2SquCA/jW4UaVDr3tNggUoAzP2ITN8X7aJOSMBoxx/3Fwfr/Woe/B0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qEvGEak2LetOD4MD691nwLRUs0r8/qOYfERz12sx9LbZE+RpPOzy+ctQTWNF+MTg2EkMgszIOsdn98IhM0o1Ptv++sz+IB1JWp7NkGJuQOTc3Lj7KNviMKiLapA5gMjpyvVrvxfAWzF3DdskhiUPdU1h67QaJTnseHJG0S4ma4Y= Received: by 10.78.147.6 with SMTP id u6mr1491102hud.1180779313258; Sat, 02 Jun 2007 03:15:13 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 2 Jun 2007 03:15:13 -0700 (PDT) Message-ID: <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> Date: Sat, 2 Jun 2007 15:45:13 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Comments on DYMO In-Reply-To: <46601AA5.2050706@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46601AA5.2050706@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 6/1/07, Alexandru Petrescu wrote: > Hi, some of these comments were raised previously I believe. > > DYMO is in draft-ietf-manet-dymo-09.txt > > > Most DYMO messages are sent with the IP destination address set to > > the link-local multicast address LL MANET ROUTERS unless otherwise > > stated. Unicast DYMO messages specified in this document are sent > > with the IP destination set to the Route.NextHopAddress of the route > > to the TargetNode. > > RREQs are specified to be sent to a LL multicast address, but nodes > are not required to join that group - they should, and probably better > with MLD and IGMP. I will put that DYMO routers should subscribe to the LL multicast group. I'm a little unclear about MLD/IGMP comment, since there is no need to inform anyone about LL subscriptions. > > When a node originates a data packet and does not have a forwarding > > route to the IP.DestinationAddress, it sends a RREQ (described in > > Section 5.3.1) to discover a route to the particular destination > > (TargetNode). > > Apparently the application must run on the router that initiates the > RREQ. Ie it is not possible to have an LFN behind an MR because MR > doesn't know when to send the RREQ. With NEMO moving networks the LFN > (Local Fixed Node) is a vanilla stack host not doing any mobility nor > much dynamic routing. A DYMO router can be responsible for prefixes of attached hosts. In this case the router manages the sequence number space for the sources in the prefixes. I thought this concept was captured in Section 5.7 that you mention below. Perhaps it should be made more explicit. Would you suggest I expand that section or flush it out more in the text directly? > Another question that comes to mind is how does a DYMO router discover > its neighbor routers? Apparently DYMO doesn't specify anything for > this. I think ND rfc2461 should be used for that purpose. DYMO "discovers" other neighboring routers by the reception of RM. An alternative and more robust mechanism like NHDP could and probably should be used in most deployments. > > The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) > > for all messages specified in this document. > > 1? Then the DYMO messages are discarded when crossing another router? > Or is the entire MANET a single subnet? All packets are LL, there are no packets that are forwarded over multiple hops. > > IP.DestinationAddress The IP address of the packet destination. For > > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For RREP > > the IP.DestinationAddress is set to the NextHopAddress toward the > > TargetNode. > > So all MANET routers must join the LL MANET routers address - is this > specified? > > > MsgHdr.HopCnt The number of hops this message has traversed. > > Why is there a need of this field when the Hop Limit in the IP header > does the same thing? Messages are not forwarded by native IP forwarding. They are received, processed, and then resulting LL messages might be sent. The MsgHdr.HopLimit controls dissemination via this mechanism. > > AddBlk.TargetNode.Address The IP address of the message TargetNode. > > In a RREQ the TargetNode is the destination for which a forwarding > > route does not exist and route discovery is being performed. In a > > RREP the target node is the RREQ OrigNode. The TargetNode address is > > the first address in the routing message. > > Why is the TargetNode address necessary in the RREP when the IP dst > field contains the same thing? In a RREP the IP destination does not contain the same thing. The IP destination is the next hop router's address toward the RREP target. > > AddBlk.OrigNode.Address The IP address of the OrigNode. This address > > is in an address block and not in the message header to allow for > > address compression and additional AddTLVs. This address is the > > second address in the message for RREQ. > > Why is this here when the src field has it too? > > > The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ > > TargetNode, so that the RREQ TargetNode receives routing information > > on how to reach the RREQ OrigNode. > > But a gratuitous message is sent without receiving any message (no RREQ > received), so how does the intermediate node know the RREQ TargetNode? > > > Before processing a RM, a node checks the IP.Destination to ensure > > that it is a link-local packet. > > Only 'link-local'? We know (by this spec) that the dst address can be > a ll multicast address or a unicast address. If the unicast address > can only have a ll scope (fe80) then the entire MANET can only be a > single subnet? > > > 5.7. Advertising Network Addresses > > > > Any node can advertise a network address by using a PREFIX_LENGTH TLV > > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising > > node) within the advertised prefix SHOULD NOT participate in the DYMO > > protocol directly and these nodes MUST be reachable by forwarding > > packets to the node advertising connectivity. Nodes other than the > > advertising node that do participate in DYMO must forward the DYMO > > control packets to the advertising node. For example, A.B.C.1 with a > > prefix length of 24 indicates all nodes with the matching A.B.C.X > > are reachable through the node with address A.B.C.1. > > Ok, but does MANET Router send Router Advertisements? Router advertisements are not DYMO routing protocol messages. Router advertisements are generally for nodes attached to routers, not router to router routing protocol communication. > > 8. Security Considerations > > > > Currently, DYMO does not specify any special security measures. > > Routing protocols, however, are prime targets for impersonation > > attacks. In networks where the node membership is not known, it is > > difficult to determine the occurrence of impersonation attacks, and > > security prevention techniques are difficult at best. However, when > > the network membership is known and there is a danger of such attacks > > What is 'node membership'? A priori knowledge of the different routers that a particular router will communicate with in the future. > > While DYMO does not place restrictions on the authentication > > mechanism used for this purpose, IPsec Authentication Message (AH) is > > an appropriate choice for cases where the nodes share an appropriate > > security association that enables the use of AH. > > How about recommending IPsec ESP too? This is an option, but generally authentication is the most important component. > > If the mobile nodes in the ad hoc network have pre-established > > security associations, the purposes for which the security > > associations are created should include that of authorizing the > > processing of DYMO control packets. Given this understanding, the > > mobile nodes should be able to use the same authentication mechanisms > > based on their IP addresses as they would have used otherwise. > > And if the mobile nodes in the ad hoc network _don't_ have > pre-established security associations? I believe this falls in the research arena. > This case is very important for MANEMO types of deployments where NEMO > moving networks come and go. > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jun 02 07:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSBg-0000qH-A7; Sat, 02 Jun 2007 07:54:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HuSBe-0000qB-BL for manet-confirm+ok@megatron.ietf.org; Sat, 02 Jun 2007 07:54:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSBe-0000q3-1d for manet@ietf.org; Sat, 02 Jun 2007 07:54:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuSBc-00005X-Ad for manet@ietf.org; Sat, 02 Jun 2007 07:54:26 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1186288ugc for ; Sat, 02 Jun 2007 04:54:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VH4RkoYXzH+qxjQxOZyU+FwvjBuGek3bh/WXx1jauz0J7w1Iw9egib5CJHTIKHNUQGj2SO21JnmIccuu3G9rC4by/aHC6ed33PUXOOiMolEwd5UJYG7bVxaHJ7N09OyepMx4JmzvFqC5ZtIsxlDS00wLWUDyH/AFf7zFqww0yGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b2Xu3ZonHnQUfQrk2butuCts4bPtP5j9XkBg1aGFxN3cmM8dXR+tpVjIcbV7bzekvz5vfum2FohCyzFCM2N2oiYDAdaFC47QjS7xiUyc4HAqO7ptMNpDo9KN9CimiO2hvMNujy9gcivPqXd8lXGLvKSMjMPX1d+n50VZ22Slhf8= Received: by 10.78.160.4 with SMTP id i4mr1520975hue.1180785263230; Sat, 02 Jun 2007 04:54:23 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 2 Jun 2007 04:54:22 -0700 (PDT) Message-ID: <374005f30706020454p6a65c2bcw141937e732038fa0@mail.gmail.com> Date: Sat, 2 Jun 2007 17:24:22 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Comments on DYMO In-Reply-To: <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Alexandru, I now understand your query about sources having to be DYMO routers. I have updated the text in relation to this issue. The text in the next revision will make it clear that the source's DYMO router is responsible for initiating route discovery on its behalf. Ian On 6/2/07, Ian Chakeres wrote: > Comments inline. > > On 6/1/07, Alexandru Petrescu wrote: > > Hi, some of these comments were raised previously I believe. > > > > DYMO is in draft-ietf-manet-dymo-09.txt > > > > > Most DYMO messages are sent with the IP destination address set to > > > the link-local multicast address LL MANET ROUTERS unless otherwise > > > stated. Unicast DYMO messages specified in this document are sent > > > with the IP destination set to the Route.NextHopAddress of the route > > > to the TargetNode. > > > > RREQs are specified to be sent to a LL multicast address, but nodes > > are not required to join that group - they should, and probably better > > with MLD and IGMP. > > I will put that DYMO routers should subscribe to the LL multicast > group. I'm a little unclear about MLD/IGMP comment, since there is no > need to inform anyone about LL subscriptions. > > > > When a node originates a data packet and does not have a forwarding > > > route to the IP.DestinationAddress, it sends a RREQ (described in > > > Section 5.3.1) to discover a route to the particular destination > > > (TargetNode). > > > > Apparently the application must run on the router that initiates the > > RREQ. Ie it is not possible to have an LFN behind an MR because MR > > doesn't know when to send the RREQ. With NEMO moving networks the LFN > > (Local Fixed Node) is a vanilla stack host not doing any mobility nor > > much dynamic routing. > > A DYMO router can be responsible for prefixes of attached hosts. In > this case the router manages the sequence number space for the sources > in the prefixes. I thought this concept was captured in Section 5.7 > that you mention below. Perhaps it should be made more explicit. Would > you suggest I expand that section or flush it out more in the text > directly? > > > Another question that comes to mind is how does a DYMO router discover > > its neighbor routers? Apparently DYMO doesn't specify anything for > > this. I think ND rfc2461 should be used for that purpose. > > DYMO "discovers" other neighboring routers by the reception of RM. An > alternative and more robust mechanism like NHDP could and probably > should be used in most deployments. > > > > The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) > > > for all messages specified in this document. > > > > 1? Then the DYMO messages are discarded when crossing another router? > > Or is the entire MANET a single subnet? > > All packets are LL, there are no packets that are forwarded over multiple hops. > > > > IP.DestinationAddress The IP address of the packet destination. For > > > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For RREP > > > the IP.DestinationAddress is set to the NextHopAddress toward the > > > TargetNode. > > > > So all MANET routers must join the LL MANET routers address - is this > > specified? > > > > > MsgHdr.HopCnt The number of hops this message has traversed. > > > > Why is there a need of this field when the Hop Limit in the IP header > > does the same thing? > > Messages are not forwarded by native IP forwarding. They are received, > processed, and then resulting LL messages might be sent. The > MsgHdr.HopLimit controls dissemination via this mechanism. > > > > AddBlk.TargetNode.Address The IP address of the message TargetNode. > > > In a RREQ the TargetNode is the destination for which a forwarding > > > route does not exist and route discovery is being performed. In a > > > RREP the target node is the RREQ OrigNode. The TargetNode address is > > > the first address in the routing message. > > > > Why is the TargetNode address necessary in the RREP when the IP dst > > field contains the same thing? > > In a RREP the IP destination does not contain the same thing. The IP > destination is the next hop router's address toward the RREP target. > > > > AddBlk.OrigNode.Address The IP address of the OrigNode. This address > > > is in an address block and not in the message header to allow for > > > address compression and additional AddTLVs. This address is the > > > second address in the message for RREQ. > > > > Why is this here when the src field has it too? > > > > > The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ > > > TargetNode, so that the RREQ TargetNode receives routing information > > > on how to reach the RREQ OrigNode. > > > > But a gratuitous message is sent without receiving any message (no RREQ > > received), so how does the intermediate node know the RREQ TargetNode? > > > > > Before processing a RM, a node checks the IP.Destination to ensure > > > that it is a link-local packet. > > > > Only 'link-local'? We know (by this spec) that the dst address can be > > a ll multicast address or a unicast address. If the unicast address > > can only have a ll scope (fe80) then the entire MANET can only be a > > single subnet? > > > > > 5.7. Advertising Network Addresses > > > > > > Any node can advertise a network address by using a PREFIX_LENGTH TLV > > > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising > > > node) within the advertised prefix SHOULD NOT participate in the DYMO > > > protocol directly and these nodes MUST be reachable by forwarding > > > packets to the node advertising connectivity. Nodes other than the > > > advertising node that do participate in DYMO must forward the DYMO > > > control packets to the advertising node. For example, A.B.C.1 with a > > > prefix length of 24 indicates all nodes with the matching A.B.C.X > > > are reachable through the node with address A.B.C.1. > > > > Ok, but does MANET Router send Router Advertisements? > > Router advertisements are not DYMO routing protocol messages. Router > advertisements are generally for nodes attached to routers, not router > to router routing protocol communication. > > > > 8. Security Considerations > > > > > > Currently, DYMO does not specify any special security measures. > > > Routing protocols, however, are prime targets for impersonation > > > attacks. In networks where the node membership is not known, it is > > > difficult to determine the occurrence of impersonation attacks, and > > > security prevention techniques are difficult at best. However, when > > > the network membership is known and there is a danger of such attacks > > > > What is 'node membership'? > > A priori knowledge of the different routers that a particular router > will communicate with in the future. > > > > While DYMO does not place restrictions on the authentication > > > mechanism used for this purpose, IPsec Authentication Message (AH) is > > > an appropriate choice for cases where the nodes share an appropriate > > > security association that enables the use of AH. > > > > How about recommending IPsec ESP too? > > This is an option, but generally authentication is the most important component. > > > > If the mobile nodes in the ad hoc network have pre-established > > > security associations, the purposes for which the security > > > associations are created should include that of authorizing the > > > processing of DYMO control packets. Given this understanding, the > > > mobile nodes should be able to use the same authentication mechanisms > > > based on their IP addresses as they would have used otherwise. > > > > And if the mobile nodes in the ad hoc network _don't_ have > > pre-established security associations? > > I believe this falls in the research arena. > > > This case is very important for MANEMO types of deployments where NEMO > > moving networks come and go. > > > > Alex > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jun 02 11:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuVlX-00013o-Bz; Sat, 02 Jun 2007 11:43:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HuVlV-00013h-R0 for manet-confirm+ok@megatron.ietf.org; Sat, 02 Jun 2007 11:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuVlV-00013Z-H2 for manet@ietf.org; Sat, 02 Jun 2007 11:43:41 -0400 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuVlU-0008Fc-Ez for manet@ietf.org; Sat, 02 Jun 2007 11:43:41 -0400 Received: (qmail 25319 invoked by uid 89); 3 Jun 2007 00:43:32 +0900 Received: from unknown (HELO IBM-T42) (59.143.41.119) by 0 with SMTP; 3 Jun 2007 00:43:32 +0900 Date: Sun, 3 Jun 2007 00:43:36 +0900 From: "Jia Hu" To: "manet" Organization: WICI X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34 Message-Id: Subject: [manet] [IAT 2007] Deadline Extended: June 16, 2007! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wiiat@kis-lab.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Apologies if you receive this more than once] Dear Colleague, In response to many requests for an extension, we are pleased to extend the paper submission deadline for IAT 2007 to ** June 16, 2007 **. Submission can be done online at: http://www.cs.sjsu.edu/wi07/iat/ We look forward to receiving your submissions soon. With best regards, Tsau Young (T.Y.) Lin PC chair of WI-IAT'07 ##################################################################### IEEE/WIC/ACM Intelligent Agent Technology 2007 CALL FOR PAPERS ##################################################################### 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07) Silicon Valley, USA, November 2-5, 2007 Official: http://www.cs.sjsu.edu/wi07/iat/ Mirror: http://www.maebashi-it.org/wi07/iat/ (to be collocated with WI'07, BIBM'07 and GrC'07) Sponsored By IEEE Computer Society Web Intelligence Consortium (WIC) Association for Computing Machinery (ACM) ##################################################################### # Conference Chair # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research # # Program Chair and Co-Chairs # T.Y. Lin, San Jose State University/UC Berkeley, USA # Jeffrey M. Bradshaw, UWF/Institute for Human and Machine Cognition, USA # Matthias Klusch, German Research Center for AI, Germany # Chengqi Zhang, University of Technology, Sydney, Australia # # Organizing Chair # Howard Ho, Manager, IBM Almaden Research Center # # IAT-WI Joint Keynote Speakers (Tentative) # # Vinton G. Cerf, Turing Award Winner, # VP and Chief Internet Evangelist, Google # Richard M. Karp, Turing Award Winner, # University of California Berkeley # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory # # (More IAT Invited Speakers will be announced) # # (Papers Due: ** June 1 **, 2007) # Accepted papers will be published in the conference proceedings # by the IEEE Computer Society Press, which are indexed by EI. ###################################################################### The 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07) will be jointly held with the 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07), the 2007 IEEE International Conference on Bioinformatics and Biomedicine (BIBM'07), and the 2007 IEEE International Conference on Granular Computing (GrC'07) for providing synergism among the four research areas. It will provide opportunities for technical collaboration beyond that of previous conferences. The four conferences will have a joint opening, keynote, reception, and banquet. Attendees only need to register for one conference and can attend workshops, sessions and tutorials across the four conferences. We are also planning a joint panel and joint paper sessions that discuss common problems in the four areas. IAT 2007 provides a leading international forum to bring together researchers and practitioners from diverse fields, such as computer science, information technology, business, education, human factors, systems engineering, and robotics, to (1) examine the design principles and performance characteristics of various approaches in intelligent agent technology, and (2) increase the cross-fertilization of ideas on the development of autonomous agents and multi-agent systems among different domains. By encouraging idea-sharing and discussions on the underlying logical, cognitive, physical, and sociological foundations as well as the enabling technologies of intelligent agents, IAT 2007 will foster the development of novel paradigms and advanced solutions in agent-based computing. +++++++++++ Highlights +++++++++++ The conference will be held in Silicon Valley, California. Many high-tech companies and three distinguished universities (Stanford, UC Berkely and UCSC) are just around the corner. The highlight of the conference is that a unique forum consisting of a half-day demo session and free discussion will be organized to link industries and academics. Leading IT companies like IBM, Google, and Yahoo etc will present at the conference. The area now known as Silicon Valley has been a center of technological development since the 1950's. The name Silicon Valley stems from the early 1970's, when the area had become the center for many semiconductor companies. While still hosting semiconductor and microprocessor companies, the region now hosts the headquarters of high tech companies of every kind, including many of the best known and most prestigious names in personal computers, Web search, Internet auctions, networking, storage, databases, etc. +++++++++++++++++++ Topics of Interest +++++++++++++++++++ The topics and areas include, but not limited to: * Autonomy-Oriented Computing (AOC) - Agent-Based Complex Systems Modeling and Development - Agent-Based Simulation - Autonomy-Oriented Modeling and Computation Methods - Behavioral Self-Organization - Complex Behavior Characterization and Engineering - Emergent Behavior - Hard Computational Problem Solving - Nature-Inspired Paradigms - Self-Organized Criticality - Self-Organized Intelligence - Swarm Intelligence * Autonomous Knowledge and Information Agents - Agent-Based Distributed Data Mining - Agent-Based Knowledge Discovery And Sharing - Autonomous Information Services - Distributed Knowledge Systems - Emergent Natural Law Discovery in Multi-Agent Systems - Evolution of Knowledge Networks - Human-Agent Interaction - Information Filtering Agents - Knowledge Aggregation - Knowledge Discovery - Ontology-Based Information Services * Agent Systems Modeling and Methodology - Agent Interaction Protocols - Cognitive Architectures - Cognitive Modeling of Agents - Emotional Modeling - Fault-Tolerance in Multi-Agent Systems - Formal Framework for Multi-Agent Systems - Information Exchanges in Multi-Agent Systems - Learning and Self-Adaptation in Multi-Agent Systems - Mobile Agent Languages and Protocols - Multi-Agent Autonomic Architectures - Multi-Agent Coordination Techniques - Multi-Agent Planning and Re-Planning - Peer-to-Peer Models for Multi-Agent Systems - Reinforcement Learning - Social Interactions in Multi-Agent Systems - Task-Based Agent Context - Task-Oriented Agents * Distributed Problem Solving - Agent-Based Grid Computing - Agent Networks in Distributed Problem Solving - Collective Group Behavior - Coordination and Cooperation - Distributed Intelligence - Distributed Search - Dynamics of Agent Groups and Populations - Efficiency and Complexity Issues - Market-Based Computing - Problem-Solving in Dynamic Environments * Autonomous Auctions and Negotiation - Agent-Based Marketplaces - Auction Markets - Combinatorial Auctions - Hybrid Negotiation - Integrative Negotiation - Mediating Agents - Pricing Agents - Thin Double Auctions * Applications - Agent-Based Assistants - Agent-Based Virtual Enterprise - Embodied Agents and Agent-Based Systems Applications - Interface Agents - Knowledge and Data Intensive Systems - Perceptive Animated Interfaces - Scalability - Social Simulation - Socially Situated Planning - Software and Pervasive Agents - Tools and Standards - Ubiquitous Systems and E-Technology Agents - Ubiquitous Software Services - Virtual Humans - XML-Based Agent Systems ++++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication ++++++++++++++++++++++++++++++++++++ High-quality papers in all IAT related areas are solicited. Paper submissions should be limited to a maximum of 7 pages in the IEEE 2-column format, the same as the camera-ready format (see the Author Guidelines of last year at http://www.computer.org/portal/pages/cscps/cps/final/iat06.xml). All submitted papers will be reviewed by the Program Committee on the basis of technical quality, relevance, significance, and clarity. Note that IAT'07 will accept ONLY on-line submissions, containing PDF versions. Please use the Submission Form on the IAT'07 website to submit your paper. Accepted papers will be published in the conference proceedings by the IEEE Computer Society Press that are indexed by EI. Submissions accepted as regular papers will be allocated 7 pages in the proceedings and accorded oral presentation times in the main conference. Submissions accepted as short papers will be allocated 4 pages in the proceedings and will have a shorter presentation time at the conference than regular papers. All co-authors will be notified at all time, for the submission, notification, and confirmation on the attendance. Submitting a paper to the conference and workshops means that, if the paper is accepted, at least one author should attend the conference to present the paper. The acceptance list and no-show list will be openly published on-line. For no-show authors, their affiliations will receive a notification. A selected number of IAT'07 accepted papers will be expanded and revised for inclusion in Web Intelligence and Agent Systems: An International Journal (http://wi-consortium.org/journal.html) and in Annual Review of Intelligent Informatics (http://www.wi-consortium.org/annual.html) More detailed instructions and the On-Line Submission Form can be found from the IAT'07 homepage: http://www.cs.sjsu.edu/wi07/iat/. +++++++++++++++++++++++++ IAT'07 Best Paper Awards +++++++++++++++++++++++++ The best paper awards will be conferred at the conference on the authors of (1) the best research paper and (2) the best application paper. Application-oriented submissions will be considered for the best application paper award. The full author list and paper title will be announced on the Web Intelligence Consortium homepage: http://wi-consortium.org/html/wicawards.html ++++++++++++++++++++ Industry/Demo-Track ++++++++++++++++++++ We solicit Industry/Demo-Track papers by the following methods. (1) Industry papers of 4 pages can be submitted on the same schedule as the research track. (2) Separate 2 page demo proposals can submitted at a later schedule. (3) Full regular paper submissions can include a demo option. That is, a full paper submissions will be asked to specify if they would like to give a demonstration; choice of demonstrations (while utilizing information from the regular reviewing process) will be selected based on value as a demonstration. For options (1) and (2), please find more detailed instructions at the homepage: http://www.cs.sjsu.edu/wi07/wi/ We are planning to arrange the Industry/Demo track in the afternoon of November 3 (before and during the conference reception), jointly with the IAT'07 Demo sessions. Leading IT companies in Silicon Valley will be invited to attend this track. ++++++++++ Workshops ++++++++++ As an important part of the conference, the workshop program will focus on new research challenges and initiatives. All papers accepted for workshops will be included in the Workshop Proceedings published by the IEEE Computer Society Press that are indexed by EI, and will be available at the workshops. Detailed information is available at the conference homepage. Note: we will not have a separate workshop registration fee (i.e., only one conference registration covers everything). ---------------------- WI-IAT 2007 Workshops: ---------------------- Title: Educating the Web-Generation (Edu4WebGen 2007) Organisers: Elisabeth Heinemann Email: elisabeth.heinemann@googlemail.com Web page: http://www.effactory.com/Edu4WebGen/ Title: Collective Intelligence on Semantic Web (CISW 2007) Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl Web page: http://intelligent.pe.kr/CISW07/ Title: New Computing Paradigms for Web Intelligence and Brain Informatics (WImBI 2007) Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: http://www.maebashi-it.org/wimbi07/WImBI2007.htm Title: Web Personalization and Recommender Systems (WPRS 2007) Organisers: Yue Xu Email: yue.xu@qut.edu.au Web page: http://www.wprs07.fit.qut.edu.au/ Title: Service Composition & SWS Challenge (SerComp & SWS Challenge 2007) Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web page: http://events.deri.at/sercomp2007/ Title: Biomedicine Applications of Web technologies (BMWT 2007) Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; whlu@mail.ncku.edu.tw Web page: http://chunnan.iis.sinica.edu.tw/BMWT2007.html Title: Intelligent Web Interaction (IWI 2007) 1st Organiser: Prof. Seiji YAMADA Email: seiji@nii.ac.jp Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ Title: Cyberinfrastucture for e-Science (CyIneS 2007) Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page: http://www.cild.iastate.edu/events/CyIneS2007/ Title: Social Media Analysis (SMA 2007) Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu Email: sma@comp.hkbu.edu.hk Web page: http://www.comp.hkbu.edu.hk/~sma/ Title: Web Security, Integrity, Privacy and Trust (WSIPT 2007) Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof. Yong Zhang Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; zhangyong076@gmail.com Web page: http://isec.hitsz.edu.cn/wsipt07/ Title: Communication between Human and Artificial Agents (CHAA 2007) Organisers: Christel Kemke Email: ckemke@cs.umanitoba.ca Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ Title: Rational, Robust, and Secure Negotiations in Multi-Agent Systems (RRS 2007) Organisers: Takayuki Ito Email: ito.takayuki@nitech.ac.jp Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ Title: P2P Computing and Autonomous Agents (P2PAA 2007) Organisers: Tarek Helmy, Khaled Ragab Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html Title: (Multi-)Agent Systems in E-Business: Concepts, Technologies and Applications (MASeB 2007) Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl; marcin.parzycki@swps.edu.pl Web page: http://software.ucv.ro/~badica_costin/maseb2007/ Title: Agent & Data Mining Interaction (ADMI 2007) Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir Gorodetsky, Justin Zhan Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: http://issel.ee.auth.gr/ADMI For more information, please visit the conference website at http://www.maebashi-it.org/wi07/iat/?index=workshop. ++++++++++ Tutorials ++++++++++ IAT'07 also welcomes Tutorial proposals. IAT'07 will include tutorials providing in-depth background on subjects that are of broad interest to the intelligent agent community. Both short (2 hours) and long (half day) tutorials will be considered. The tutorials will be part of the main conference technical program. Detailed information is available at the conference homepage. Note: we will not have a separate tutorials registration fee (i.e., only one conference registration covers everything). ++++++++++++++++ Important Dates ++++++++++++++++ Workshop proposal submission: March 20, 2007 Electronic submission of full papers: ** June 1, 2007 ** Tutorial proposal submission: June 15, 2007 Notification of paper acceptance: July 22, 2007 Camera-ready copies of accepted papers: August 17, 2007 Conference: November 2-5, 2007 ++++++++++++++++++++++++ Conference Organization ++++++++++++++++++++++++ Conference Chair: * Andrei Broder, Yahoo! Research, USA Program Chair: * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA IAT Program Co-Chairs: * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Matthias Klusch, German Research Center for AI, Germany * Chengqi Zhang, University of Technology, Sydney, Australia IAT Program Vice Co-chairs * Longbing cao University of Technology Sydney Australia * Joseph A. Giampapa Carnegie Mellon University USA * Maria Gini University of Minnesota USA * Vladimir Gorodetsky St. Petersburg Institute for Informatics and Automation Russia * Alessio Lomuscio Imperial College London UK * Zbigniew Ras University of North Carolina USA * Marius C. Silaghi Florida Institute of Technology USA * Makoto Yokoo Kyushu University Japan WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev Motwani, Stanford University, USA WI Program Vice Co-chairs * Ajith Abraham Yonsei University South Korea * Peter Brusilovsky University of Pittsburgh USA * Ashish Goel Stanford University USA * Ramanathan V. Guha Google USA * Jane Yung-jen Hsu National Taiwan University Taiwan * Ravi Kumar Yahoo! Research USA * Jie Lu University of Technology Sydney Australia * Tsuyoshi Murata Tokyo Institute of Technology Japan * York Sure Institute AIFB, University of Karlsruhe Germany * Pang-Ning Tan Michigan State University USA * Bhavani Thuraisingham University of Texas at Dallas USA * Mohammed Zaki Rensselaer Polytechnic Institute USA Organizing Chair: * Howard Ho, IBM Almaden Research Center, USA Workshop Co-Chairs: * Vijay Raghavan, University of Louisiana, USA * Yuefeng Li, Queensland University of Technology, Australia Tutorial Chair: * Pawan Lingras, Saint Mary's University, Canada Industry/Demo-Track Chair: * Jianchang Mao, Yahoo! Inc., USA Local Accommodations Co-Chairs: * David Scot Taylor, San Jose State University, USA * Tom Qi Zhang, Google, USA Publicity Chair: * James Wang, Clemson University, USA (chair) Publicity Co-Chairs: * Martine De Cock, Ghent University, Belgium * Jia Hu, International WIC Institute, China * Debajyoti Mukhopadhyay, West Bengal University of Technology, India IEEE-CS-TCII Chair: * Ning Zhong, Maebashi Institute of Technology, Japan ACM-SIGART Chair * Maria Gini, University of Minnesota, USA WIC Co-Chairs/Directors: * Ning Zhong, Maebashi Institute of Technology, Japan * Jiming Liu, University of Windsor, Canada WIC Advisory Board: * Edward A. Feigenbaum, Stanford University, USA * Setsuo Ohsuga, Waseda University, Japan * Benjamin Wah, University of Illinois, Urbana-Champaign, USA * Philip Yu, IBM Thomas J. Watson Research Center, USA * L.A. Zadeh, University of California Berkeley, USA WIC Tech. Committee & WI/IAT Steering Committee: * Jeffrey Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Nick Cercone, York University, Canada * Dieter Fensel, University of Innsbruck/Digital Enterprise Research Institute, Austria * Georg Gottlob, Oxford University, UK * Lakhmi Jain, University of South Australia, Australia * Jianchang Mao, Yahoo! Inc., USA * Pierre Morizet-Mahoudeaux, Compiegne University of Technology, France * Hiroshi Motoda, Osaka University, Japan * Toyoaki Nishida, Kyoto University, Japan * Andrzej Skowron, Warsaw University, Poland * Jinglong Wu, Kagawa University, Japan * Xindong Wu, University of Vermont, USA * Yiyu Yao, University of Regina, Canada Webmaster: * Albert Sutojo, San Jose State University, USA Abbreviation: IAT 2007, IAT2007, IAT'2007, IAT'07, IAT07, IAT 07, IAT-07, IAT-2007 *** Contact Information *** Jia Hu International WIC Institute, China E-mail: hujia@kis-lab.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 00:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4Pp-0004XB-4z; Mon, 04 Jun 2007 00:43:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hv4Pl-0004Kx-1Q for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 00:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4Pj-0004HQ-SE for manet@ietf.org; Mon, 04 Jun 2007 00:43:32 -0400 Received: from pop3.ajou.ac.kr ([202.30.0.18] helo=mail.ajou.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv4Pg-0000V3-FA for manet@ietf.org; Mon, 04 Jun 2007 00:43:31 -0400 Received: from ajou.ac.kr (127.0.0.1) by mail.ajou.ac.kr with ESMTP imoxion SensMail SmtpServer 5.0 id <46639baf3fea0ef07ee98271> for from ; Mon, 04 Jun 2007 13:43:41 +0900 Message-ID: <46639b133fed@imoxion.com> Date: Mon, 4 Jun 2007 13:43:44 +0900 (KST) From: Zeeshan Hameed Mir To: manet@ietf.org, rsn@ietf.org, tccc@cs.columbia.edu, 6lowpan@lists.ietf.org, dbworld-request@cs.wisc.edu MIME-Version: 1.0 X-Priority: 3 X-Spam-Score: 1.3 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Subject: [manet] USN 2007 Extended Deadline to June 15 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573415227==" Errors-To: manet-bounces@ietf.org --===============1573415227== Content-Type: multipart/alternative; boundary="----=_Part_2714154_61393.1180932224038" ------=_Part_2714154_61393.1180932224038 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 W1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3Bp ZXMgb2YgdGhpcyBDRlBdIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KQ0FMTCBGT1IgUEFQRVJTIGZvciBVU04gMjAwNyANCg0KVGhlIDNy ZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFViaXF1aXRvdXMgU2Vuc29yIE5l dHdvcmtzIChVU04pIA0KDQpodHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvLCBEZWNlbWJl ciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pIA0KDQpUbyBiZSBoZWxkIGluIGNvbmp1bmN0 aW9uIHdpdGggRVVDIDIwMDcgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KDQoNCkltcG9ydGFudCBEYXRlczogDQoNCiogU3VibWlzc2lvbiBE dWU6IEp1bmUgMTUsIDIwMDcgKGV4dGVuZGVkIGRlYWRsaW5lKSANCg0KKiBBY2NlcHRhbmNlIG5v dGlmaWNhdGlvbjogQXVndXN0IDYsIDIwMDcgDQoNCiogQ2FtZXJhLXJlYWR5IGR1ZTogU2VwdGVt YmVyIDQsIDIwMDcgDQoNCiAgDQpBYm91dCB0aGUgd29ya3Nob3A6IA0KDQpUaGUgcHVycG9zZSBv ZiBVU04gMjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBhbGwg dGhlIGNoYWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVpdG91 cyBTZW5zb3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBvcHBv cnR1bml0eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dpZXMg b2YgdGhlIG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJlc2Vh cmNoZXJzIHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIA0KICANCg0KVG9waWNz IG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzogDQoNCqGk ICAgICAgICAgUkZJRCBTeXN0ZW1zIGFuZCBBcmNoaXRlY3R1cmUgDQoNCqGkICAgICAgICAgUkZJ RCBNaWRkbGV3YXJlIERlc2lnbiANCg0KoaQgICAgICAgICBBbnRpLWNvbGxpc2lvbiBhbGdvcml0 aG1zIA0KDQqhpCAgICAgICAgIE1vYmlsZSBSRklEIFN5c3RlbXMgYW5kIEFwcGxpY2F0aW9ucyAN Cg0KoaQgICAgICAgICBEYXRhIE1vZGVsaW5nIGFuZCBNYW5hZ2VtZW50IA0KDQqhpCAgICAgICAg IEVtYmVkZGVkIFJGSUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSANCg0KoaQgICAgICAgICBT ZW5zb3IgTmV0d29yayBBcmNoaXRlY3R1cmVzIGFuZCBQcm90b2NvbHMgDQoNCqGkICAgICAgICAg TmV0d29yayBwcm90b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyANCg0KoaQgICAgICAgICBE aXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9uaXph dGlvbiANCg0KoaQgICAgICAgICBDcm9zcyBMYXllciBhbmQgRW5lcmd5IEVmZmljaWVudCBEZXNp Z24gDQoNCqGkICAgICAgICAgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQgRGF0 YWJhc2UgDQoNCqGkICAgICAgICAgQ29leGlzdGVuY2Ugb2YgUkZJRCAmIFVTTiANCg0KoaQgICAg ICAgICBRb1MgYW5kIFJlYWwtVGltZSBJc3N1ZXMgDQoNCqGkICAgICAgICAgU2VjdXJpdHkgYW5k IHByaXZhY3kgaXNzdWVzIA0KDQqhpCAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBpbiBMYXJn ZS1zY2FsZSBEZXBsb3ltZW50IA0KDQqhpCAgICAgICAgIENvZXhpc3RlbmNlIG9mIFJGSUQgJiBV U04gDQoNCqGkICAgICAgICAgTm92ZWwgUkZJRCBhbmQgVVNOIEFwcGxpY2F0aW9ucyANCiAgDQoN CldvcmtzaG9wIENoYWlycyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQpZb3VuZy1CYWUgS28s IEFqb3UgVW5pdmVyc2l0eSwgS29yZWEgDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24g UmVzZWFyY2gsIFVTQSANCg0KICANCg0KU3RlZXJpbmcgQ29tbWl0dGVlIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSANCg0KSm9uZ3N1ayBDaGFlLCBFVFJJLCBLb3JlYSANCg0KU2V1bmctV2hhIFlv bywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSANCg0KWXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwgQ2hp YW8gVHVuZyBVbml2LiwgVGFpd2FuIA0KDQpEYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFuZCBD b21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5LCBLb3JlYSANCg0KICANCg0KUHJvZ3JhbSBDb21taXR0 ZWUgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCkJ5dW5naHVuIFNvbmcsIEtFVEksIEtv cmVhIA0KDQpDaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5LCBVU0EgDQoNCkNo aWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW4gDQoNCkRvbmctS3l1biBL aW0sIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KSmFlLUh5dW4gS2lt LCBBam91IFVuaXZlcnNpdHksIEtvcmVhIA0KDQpKYXZpZXIgR29tZXosIE5hdGlvbmFsIFVuaXZl cnNpdHkgb2YgTWV4aWNvLCBNZXhpY28gDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24g UmVzZWFyY2gsIFVTQSANCg0KS3VpIFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5hZGEg DQoNCkxpbmctSnloIENoZW4sIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBUYWl3 YW4gDQoNCk1pbmVvIFRha2FpLCBVQ0xBLCBVU0EgDQoNCk1pbmctSmVyIFRzYWksIE5hdGlvbmFs IFRzaW5nLUh1YSBVbml2LiwgVGFpd2FuIA0KDQpNaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVsZWNv bSwgRnJhbmNlIA0KDQpNb2hhbWVkIFlvdW5pcywgVW5pdmVyc2l0eSBvZiBNYXJ5bGFuZCwgVVNB IA0KDQpPemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleSANCg0KU2FhZCBC aWF6LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBIA0KDQpUYWVreXVuZyBLd29uLCBTZW91bCBOYXRp b25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KVGFlLUppbiBMZWUsIFN1bmdreXVua3dhbiBVbml2 ZXJzaXR5LCBLb3JlYSANCg0KWXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5nIENoZW5nIFVu aXZlcnNpdHksIFRhaXdhbiANCg0KV2VpIExvdSwgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVuaXZl cnNpdHksIENoaW5hIA0KDQpXZW4tQ2hpaCBQZW5nLCBOYXRpb25hbCBDaGlhbyBUdW5nIFVuaXYu LCBUYWl3YW4gDQoNCldvbmp1biBMZWUsIEtvcmVhIFVuaXZlcnNpdHksIEtvcmVhIA0KDQotLS0t LQ0KDQpaZWVzaGFuIEhhbWVlZCBNaXIsDQpBam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVhDQoN Cg== ------=_Part_2714154_61393.1180932224038 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9J3RleHQvY3NzJz4gUCB7cGFkZGluZzowcHg7IG1hcmdp bjoycHg7IGJvcmRlcjowcHg7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6J2FyaWFsJzt9ICBi b2R5IHtwYWRkaW5nOjVweDsgbWFyZ2luOjBweDsgYm9yZGVyOjBweDtmb250LXNpemU6MTNweDtm b250LWZhbWlseTonYXJpYWwnO30gPC9zdHlsZT48L2hlYWQ+PGJvZHk+PHRhYmxlIHdpZHRoPTk5 JSBhbGlnbj1jZW50ZXIgaGVpZ2h0PScxMDAnPjx0ciB2YWxpZ249dG9wPjx0ZD48Zm9udCBzaXpl PTI+PFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+W1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2 ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBDRlBdPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZP TlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPkNBTEwgRk9SIFBBUEVSUyBmb3IgVVNOIDIwMDc8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+VGhlIDNyZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFVi aXF1aXRvdXMgU2Vuc29yIE5ldHdvcmtzIChVU04pIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1F Ti1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYi Pmh0dHA6Ly91bnMuYWpvdS5hYy5rci9+dXNuMjAwNy8sIERlY2VtYmVyIDE3LTIwLCAyMDA3LCBU YWlwZWksIFRhaXdhbik8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VG8gYmUgaGVsZCBpbiBj b25qdW5jdGlvbiB3aXRoIEVVQyAyMDA3PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+SW1wb3J0YW50IERhdGVzOjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj4qIFN1Ym1pc3Npb24gRHVlOiBKdW5lIDE1LCAyMDA3IChleHRlbmRlZCBkZWFkbGluZSk8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBBY2NlcHRhbmNlIG5vdGlmaWNhdGlvbjogQXVn dXN0IDYsIDIwMDcgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBDYW1lcmEtcmVhZHkgZHVl OiBTZXB0ZW1iZXIgNCwgMjAwNyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQ QU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5BYm91dCB0aGUgd29ya3Nob3A6PC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPlRoZSBwdXJwb3NlIG9mIFVTTiAyMDA3IGlzIHRvIGVzdGFibGlzaCBhIGRpc2N1 c3Npb24gZnJhbWV3b3JrIG9uIGFsbCB0aGUgY2hhbGxlbmdlcyByYWlzZWQgZnJvbSB0aGUgZXZv bHV0aW9uIG9mIHRoZSBVYmlxdWl0b3VzIFNlbnNvciBOZXR3b3JrcyBhbmQgUkZJRCB0ZWNobm9s b2dpZXMuIEFzIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIG9idGFpbiBhbiBpbnNpZ2h0IG9uIHRo ZSBsZWFkaW5nIHRlY2hub2xvZ2llcyBvZiB0aGUgbmV4dCBwZXJ2YXNpdmUgZXJhLCBVU04gMjAw NyB3YW50cyB0byBpbnZpdGUgcmVzZWFyY2hlcnMgdG8gcHJlc2VudCBhbmQgZGlzY3VzcyB0aGVp ciBpZGVhcy4gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fu cy1zZXJpZiI+VG9waWNzIG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGlt aXRlZCB0bzogPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFJGSUQgU3lzdGVtcyBhbmQgQXJjaGl0ZWN0dXJlIDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRklEIE1pZGRsZXdhcmUg RGVzaWduIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBBbnRpLWNvbGxpc2lvbiBhbGdvcml0aG1zIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNb2JpbGUgUkZJRCBTeXN0ZW1zIGFu ZCBBcHBsaWNhdGlvbnMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IERhdGEgTW9kZWxpbmcgYW5kIE1hbmFnZW1lbnQgPC9TUEFOPjwvRk9O VD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEVtYmVkZGVkIFJG SUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4t VVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6h pCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2Vuc29yIE5ldHdvcmsgQXJjaGl0ZWN0dXJl cyBhbmQgUHJvdG9jb2xzIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBOZXR3b3JrIHByb3RvY29scywgZS5nLiwgTUFDIGFuZCByb3V0aW5n IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEaXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9u aXphdGlvbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQ3Jvc3MgTGF5ZXIgYW5kIEVuZXJneSBFZmZpY2llbnQgRGVzaWduIDwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVU04gTWlk ZGxld2FyZSBJc3N1ZXMsIGUuZy4sIE9TIGFuZCBEYXRhYmFzZSA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29leGlzdGVuY2Ugb2YgUkZJ RCAmYW1wOyBVU04gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFFvUyBhbmQgUmVhbC1UaW1lIElzc3VlcyA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VjdXJpdHkgYW5kIHByaXZh Y3kgaXNzdWVzIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBOZXR3b3JrIE1hbmFnZW1lbnQgaW4gTGFyZ2Utc2NhbGUgRGVwbG95bWVudCA8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Q29leGlzdGVuY2Ugb2YgUkZJRCAmYW1wOyBVU04gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVO LVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+ oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5vdmVsIFJGSUQgYW5kIFVTTiBBcHBsaWNh dGlvbnMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48L1NQQU4+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+V29ya3Nob3AgQ2hhaXJzPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+ PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0t LS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+WW91bmctQmFlIEtvLCBBam91IFVu aXZlcnNpdHksIEtvcmVhIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkthbmctV29uIExlZSwg SUJNIFQuSiBXYXRzb24gUmVzZWFyY2gsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4m bmJzcDs8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+U3RlZXJpbmcgQ29tbWl0dGVlIDwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBz YW5zLXNlcmlmIj5Kb25nc3VrIENoYWUsIEVUUkksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPlNldW5nLVdoYSBZb28sIEFqb3UgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+WXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwgQ2hpYW8gVHVuZyBVbml2Liwg VGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkRhZXlvdW5nIEtpbSwgSW5mb3JtYXRp b24gYW5kIENvbW11bmljYXRpb25zIFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48 L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Qcm9ncmFtIENvbW1p dHRlZTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5CeXVuZ2h1biBTb25nLCBLRVRJLCBLb3JlYTwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5DaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5 LCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Q2hpaC1ZdW5nIENoYW5nLCBUYW1rYW5n IFVuaXZlcnNpdHksIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Eb25nLUt5dW4g S2ltLCBLeXVuZ3Bvb2sgTmF0aW9uYWwgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+SmFlLUh5dW4gS2ltLCBBam91IFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwv Rk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPkphdmllciBHb21leiwgTmF0aW9uYWwgVW5pdmVyc2l0eSBvZiBN ZXhpY28sIE1leGljbzwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQ QU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5LYW5nLVdvbiBMZWUsIElC TSBULkogV2F0c29uIFJlc2VhcmNoLCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+ IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+S3Vp IFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5hZGE8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+TGluZy1KeWggQ2hlbiwgSW5zdGl0dXRlIG9mIEluZm9ybWF0aW9uIFNjaWVuY2UsIFRh aXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5NaW5lbyBUYWthaSwgVUNMQSwgVVNBPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1pbmctSmVyIFRzYWksIE5hdGlvbmFsIFRzaW5nLUh1 YSBVbml2LiwgVGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1pc2NoYSBEb2hsZXIs IEZyYW5jZSBUZWxlY29tLCBGcmFuY2U8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+TW9oYW1l ZCBZb3VuaXMsIFVuaXZlcnNpdHkgb2YgTWFyeWxhbmQsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj5Pemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleTwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5TYWFkIEJpYXosIEF1YnVybiBVbml2ZXJzaXR5LCBVU0E8L1NQ QU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VGFla3l1bmcgS3dvbiwgU2VvdWwgTmF0aW9uYWwgVW5p dmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VGFlLUppbiBMZWUsIFN1 bmdreXVua3dhbiBVbml2ZXJzaXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Z dWgtU2h5YW4gQ2hlbiwgTmF0aW9uYWwgQ2h1bmcgQ2hlbmcgVW5pdmVyc2l0eSwgVGFpd2FuPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldlaSBMb3UsIEhvbmcgS29uZyBQb2x5dGVjaG5pYyBV bml2ZXJzaXR5LCBDaGluYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48 L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5XZW4tQ2hpaCBQZW5n LCBOYXRpb25hbCBDaGlhbyBUdW5nIFVuaXYuLCBUYWl3YW48L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+V29uanVuIExlZSwgS29yZWEgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUz4tLS0t LTwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTPjwvU1BBTj4mbmJzcDs8L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTPlplZXNoYW4gSGFtZWVkIE1pciw8L1NQQU4+PC9QPg0KPFA+PFNQQU4g bGFuZz1FTi1VUz5Bam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVhPC9QPjwvU1BBTj48L2ZvbnQ+ PC90ZD48L3RyPjwvdGFibGU+PGJyPg0KPGltZyBpZD0nbWFpbGV4cCcgd2lkdGg9MCBoZWlnaD0w IGJvcmRlcj0wIHNyYz0naHR0cDovL21haWwuYWpvdS5hYy5rcjo4MC9tYWlsX3JlY2VpcHRfY2hl Y2suanNwP3VrZXk9NDY2MzliMTIzZmVhYzBkODk2Y2E3ZmI1JnVzZXJpZD16aG1pciZhaG9zdD1h am91X2FjX2tyJz48L2JvZHk+PC9odG1sPg== ------=_Part_2714154_61393.1180932224038-- --===============1573415227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1573415227==-- From manet-bounces@ietf.org Mon Jun 04 04:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv88k-0008Bj-Qn; Mon, 04 Jun 2007 04:42:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hv88i-00088f-2z for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 04:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv88h-00086D-J9 for manet@ietf.org; Mon, 04 Jun 2007 04:42:11 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv88g-0003fY-BB for manet@ietf.org; Mon, 04 Jun 2007 04:42:11 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1016950wxc for ; Mon, 04 Jun 2007 01:42:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=tMxq/6jwed3z7ilQ/iSwal1Eo+Al8SeIc1SsTFDbBKC5tBUH2l+1k6q1Af/ISIOYhZ06stw2EPkmMpovxrBMb+F4qNckIty6dvSekciabcGQwug4yju2sQV3j8NnDqJT5OiSsxlhbcLEztCMdKuXG2dJpg2ZqPq9B6/I8qCZ4XU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=H3UGD11a44lgMXjrGCzu2DrDdWrSuUVNoT9azfWITkWRTT3UL/JD0E7vpHf4fuEuYE8sh1thPeWFx532aUOWYBUebvjL6F0N1DQAqhaFtskC4VdzsNYXYBcfpXZCrnTid9hMEuZu27X7SKFKfGnQR/7cEJ1Nt/FgFGHPhNkLXoM= Received: by 10.90.81.14 with SMTP id e14mr3325618agb.1180946530076; Mon, 04 Jun 2007 01:42:10 -0700 (PDT) Received: by 10.90.102.9 with HTTP; Mon, 4 Jun 2007 01:42:10 -0700 (PDT) Message-ID: Date: Mon, 4 Jun 2007 10:42:10 +0200 From: "Abdelouahid Derhab" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [manet] GPSR source code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0926372555==" Errors-To: manet-bounces@ietf.org --===============0926372555== Content-Type: multipart/alternative; boundary="----=_Part_20868_20679927.1180946530055" ------=_Part_20868_20679927.1180946530055 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I am looking for the source code for GPSR routing protocol implemented under glomosim. Is it possible to get it? Thanks in advance. Best regards. Abdelouahid. --=20 Name: Abdelouahid Derhab Affiliation: Basic software laboratory, CERIST. Address: Rue des 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg=E9ri= e Tel +213 21 91 62 05/08 Fax +213 21 91 21 26 ------=_Part_20868_20679927.1180946530055 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
I am looking for the source code for GPSR  routing protocol imple= mented under glomosim. Is it possible to get it?
 
Thanks in advance.
 
Best regards.
Abdelouahid.

--
Name: Abdelouahid Derhab
<= br>Affiliation: Basic software laboratory, CERIST.

Address: Rue des = 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg=E9rie

Tel +213= 21 91 62 05/08

Fax +213 21 91 21 26
------=_Part_20868_20679927.1180946530055-- --===============0926372555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0926372555==-- From manet-bounces@ietf.org Mon Jun 04 08:07:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBL3-0004pJ-Dc; Mon, 04 Jun 2007 08:07:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvBL1-0004pC-6t for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 08:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBL0-0004p4-TW for manet@ietf.org; Mon, 04 Jun 2007 08:07:06 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvBL0-0007H9-Ef for manet@ietf.org; Mon, 04 Jun 2007 08:07:06 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1180958825!22304555!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11982 invoked from network); 4 Jun 2007 12:07:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 4 Jun 2007 12:07:05 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54C75xS011916; Mon, 4 Jun 2007 05:07:05 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l54C74a6017570; Mon, 4 Jun 2007 07:07:04 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l54C738m017556; Mon, 4 Jun 2007 07:07:03 -0500 (CDT) Message-ID: <46640066.90907@gmail.com> Date: Mon, 04 Jun 2007 14:07:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Comments on DYMO References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> <374005f30706020454p6a65c2bcw141937e732038fa0@mail.gmail.com> In-Reply-To: <374005f30706020454p6a65c2bcw141937e732038fa0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Alexandru, > > I now understand your query about sources having to be DYMO routers. I > have updated the text in relation to this issue. The text in the next > revision will make it clear that the source's DYMO router is > responsible for initiating route discovery on its behalf. Hi Ian, what does the text look like? Alex > > Ian > > On 6/2/07, Ian Chakeres wrote: >> Comments inline. >> >> On 6/1/07, Alexandru Petrescu wrote: >> > Hi, some of these comments were raised previously I believe. >> > >> > DYMO is in draft-ietf-manet-dymo-09.txt >> > >> > > Most DYMO messages are sent with the IP destination address set to >> > > the link-local multicast address LL MANET ROUTERS unless otherwise >> > > stated. Unicast DYMO messages specified in this document are sent >> > > with the IP destination set to the Route.NextHopAddress of the route >> > > to the TargetNode. >> > >> > RREQs are specified to be sent to a LL multicast address, but nodes >> > are not required to join that group - they should, and probably better >> > with MLD and IGMP. >> >> I will put that DYMO routers should subscribe to the LL multicast >> group. I'm a little unclear about MLD/IGMP comment, since there is no >> need to inform anyone about LL subscriptions. >> >> > > When a node originates a data packet and does not have a forwarding >> > > route to the IP.DestinationAddress, it sends a RREQ (described in >> > > Section 5.3.1) to discover a route to the particular destination >> > > (TargetNode). >> > >> > Apparently the application must run on the router that initiates the >> > RREQ. Ie it is not possible to have an LFN behind an MR because MR >> > doesn't know when to send the RREQ. With NEMO moving networks the LFN >> > (Local Fixed Node) is a vanilla stack host not doing any mobility nor >> > much dynamic routing. >> >> A DYMO router can be responsible for prefixes of attached hosts. In >> this case the router manages the sequence number space for the sources >> in the prefixes. I thought this concept was captured in Section 5.7 >> that you mention below. Perhaps it should be made more explicit. Would >> you suggest I expand that section or flush it out more in the text >> directly? >> >> > Another question that comes to mind is how does a DYMO router discover >> > its neighbor routers? Apparently DYMO doesn't specify anything for >> > this. I think ND rfc2461 should be used for that purpose. >> >> DYMO "discovers" other neighboring routers by the reception of RM. An >> alternative and more robust mechanism like NHDP could and probably >> should be used in most deployments. >> >> > > The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) >> > > for all messages specified in this document. >> > >> > 1? Then the DYMO messages are discarded when crossing another router? >> > Or is the entire MANET a single subnet? >> >> All packets are LL, there are no packets that are forwarded over >> multiple hops. >> >> > > IP.DestinationAddress The IP address of the packet destination. For >> > > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For RREP >> > > the IP.DestinationAddress is set to the NextHopAddress toward the >> > > TargetNode. >> > >> > So all MANET routers must join the LL MANET routers address - is this >> > specified? >> > >> > > MsgHdr.HopCnt The number of hops this message has traversed. >> > >> > Why is there a need of this field when the Hop Limit in the IP header >> > does the same thing? >> >> Messages are not forwarded by native IP forwarding. They are received, >> processed, and then resulting LL messages might be sent. The >> MsgHdr.HopLimit controls dissemination via this mechanism. >> >> > > AddBlk.TargetNode.Address The IP address of the message TargetNode. >> > > In a RREQ the TargetNode is the destination for which a forwarding >> > > route does not exist and route discovery is being performed. In a >> > > RREP the target node is the RREQ OrigNode. The TargetNode address is >> > > the first address in the routing message. >> > >> > Why is the TargetNode address necessary in the RREP when the IP dst >> > field contains the same thing? >> >> In a RREP the IP destination does not contain the same thing. The IP >> destination is the next hop router's address toward the RREP target. >> >> > > AddBlk.OrigNode.Address The IP address of the OrigNode. This address >> > > is in an address block and not in the message header to allow for >> > > address compression and additional AddTLVs. This address is the >> > > second address in the message for RREQ. >> > >> > Why is this here when the src field has it too? >> > >> > > The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ >> > > TargetNode, so that the RREQ TargetNode receives routing information >> > > on how to reach the RREQ OrigNode. >> > >> > But a gratuitous message is sent without receiving any message (no RREQ >> > received), so how does the intermediate node know the RREQ TargetNode? >> > >> > > Before processing a RM, a node checks the IP.Destination to ensure >> > > that it is a link-local packet. >> > >> > Only 'link-local'? We know (by this spec) that the dst address can be >> > a ll multicast address or a unicast address. If the unicast address >> > can only have a ll scope (fe80) then the entire MANET can only be a >> > single subnet? >> > >> > > 5.7. Advertising Network Addresses >> > > >> > > Any node can advertise a network address by using a PREFIX_LENGTH TLV >> > > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising >> > > node) within the advertised prefix SHOULD NOT participate in the DYMO >> > > protocol directly and these nodes MUST be reachable by forwarding >> > > packets to the node advertising connectivity. Nodes other than the >> > > advertising node that do participate in DYMO must forward the DYMO >> > > control packets to the advertising node. For example, A.B.C.1 with a >> > > prefix length of 24 indicates all nodes with the matching A.B.C.X >> > > are reachable through the node with address A.B.C.1. >> > >> > Ok, but does MANET Router send Router Advertisements? >> >> Router advertisements are not DYMO routing protocol messages. Router >> advertisements are generally for nodes attached to routers, not router >> to router routing protocol communication. >> >> > > 8. Security Considerations >> > > >> > > Currently, DYMO does not specify any special security measures. >> > > Routing protocols, however, are prime targets for impersonation >> > > attacks. In networks where the node membership is not known, it is >> > > difficult to determine the occurrence of impersonation attacks, and >> > > security prevention techniques are difficult at best. However, when >> > > the network membership is known and there is a danger of such attacks >> > >> > What is 'node membership'? >> >> A priori knowledge of the different routers that a particular router >> will communicate with in the future. >> >> > > While DYMO does not place restrictions on the authentication >> > > mechanism used for this purpose, IPsec Authentication Message (AH) is >> > > an appropriate choice for cases where the nodes share an appropriate >> > > security association that enables the use of AH. >> > >> > How about recommending IPsec ESP too? >> >> This is an option, but generally authentication is the most important >> component. >> >> > > If the mobile nodes in the ad hoc network have pre-established >> > > security associations, the purposes for which the security >> > > associations are created should include that of authorizing the >> > > processing of DYMO control packets. Given this understanding, the >> > > mobile nodes should be able to use the same authentication mechanisms >> > > based on their IP addresses as they would have used otherwise. >> > >> > And if the mobile nodes in the ad hoc network _don't_ have >> > pre-established security associations? >> >> I believe this falls in the research arena. >> >> > This case is very important for MANEMO types of deployments where NEMO >> > moving networks come and go. >> > >> > Alex >> > >> > ______________________________________________________________________ >> > This email has been scanned by the MessageLabs Email Security System. >> > For more information please visit http://www.messagelabs.com/email >> > ______________________________________________________________________ >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www1.ietf.org/mailman/listinfo/manet >> > >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 08:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBlK-0004Kq-7x; Mon, 04 Jun 2007 08:34:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvBlJ-0004Kl-9R for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 08:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBlI-0004Kd-W2 for manet@ietf.org; Mon, 04 Jun 2007 08:34:16 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvBlI-0003Wb-IE for manet@ietf.org; Mon, 04 Jun 2007 08:34:16 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1180960455!15321483!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19351 invoked from network); 4 Jun 2007 12:34:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 4 Jun 2007 12:34:15 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54CYFdw019310; Mon, 4 Jun 2007 05:34:15 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l54CYEWp017305; Mon, 4 Jun 2007 07:34:15 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l54CYCMp017280; Mon, 4 Jun 2007 07:34:13 -0500 (CDT) Message-ID: <466406C3.60603@gmail.com> Date: Mon, 04 Jun 2007 14:34:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Comments on DYMO References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> In-Reply-To: <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Comments inline. > > On 6/1/07, Alexandru Petrescu wrote: >> Hi, some of these comments were raised previously I believe. >> >> DYMO is in draft-ietf-manet-dymo-09.txt >> >>> Most DYMO messages are sent with the IP destination address set >>> to the link-local multicast address LL MANET ROUTERS unless >>> otherwise stated. Unicast DYMO messages specified in this >>> document are sent with the IP destination set to the >>> Route.NextHopAddress of the route to the TargetNode. >> >> RREQs are specified to be sent to a LL multicast address, but nodes >> are not required to join that group - they should, and probably >> better with MLD and IGMP. > > I will put that DYMO routers should subscribe to the LL multicast > group. I'm a little unclear about MLD/IGMP comment, since there is no > need to inform anyone about LL subscriptions. I'm not sure why you say there is no need to inform anyone about LL subscriptions? I think only the routers that subscribed to that group should receive the DYMO Routing Message. This is achieved by sending a message saying it's interested in that group. Then the DYMO RMs are sent only to the routers interested in, bandwidth is saved. >>> When a node originates a data packet and does not have a >>> forwarding route to the IP.DestinationAddress, it sends a RREQ >>> (described in Section 5.3.1) to discover a route to the >>> particular destination (TargetNode). >> >> Apparently the application must run on the router that initiates >> the RREQ. Ie it is not possible to have an LFN behind an MR >> because MR doesn't know when to send the RREQ. With NEMO moving >> networks the LFN (Local Fixed Node) is a vanilla stack host not >> doing any mobility nor much dynamic routing. > > A DYMO router can be responsible for prefixes of attached hosts. In a MANEMO topology the Mobile Router (presumably the DYMO router) is routing not only for hosts directly attached to it but also for all other hosts in the NEMO moving network (presumably separated from it by Fixed Routers). The prefixes of the directly attached hosts and of the hosts attached on FR can be completely different (not aggregated). So a DYMO router, if it wants to send RREQ to other DYMO routers it should do so for all hosts directly or indirectly (through FR) attached to it, ie hosts in the NEMO moving network. The DYMO sourter, if it wants to send RREP when requested by other DYMO routers, should send RREP containing not only the prefix of its directly attached hosts but also the prefixes of hosts that can be attached on the Fixed Router. > In this case the router manages the sequence number space for the > sources in the prefixes. I thought this concept was captured in > Section 5.7 that you mention below. Perhaps it should be made more > explicit. Would you suggest I expand that section or flush it out > more in the text directly? Sorry, I don't yet have a full understanding of DYMO sequence numbers. I'll have to see this. >> Another question that comes to mind is how does a DYMO router >> discover its neighbor routers? Apparently DYMO doesn't specify >> anything for this. I think ND rfc2461 should be used for that >> purpose. > > DYMO "discovers" other neighboring routers by the reception of RM. Wouldn't it be more flexible if discovering was allowed too by the reception of periodic unsolicited advertisements? Like hosts discover routers by either receiving unsolicitied advertisements or 'pro-actively' requesting one? I think yes IMHO. > An alternative and more robust mechanism like NHDP could and probably > should be used in most deployments. There are more ND deployments than NHDP thus ND would be better I believe. >>> The IP TTL (IP Hop Limit) field for DYMO messages is set to one >>> (1) for all messages specified in this document. >> >> 1? Then the DYMO messages are discarded when crossing another >> router? Or is the entire MANET a single subnet? > > All packets are LL, there are no packets that are forwarded over > multiple hops. Does this mean that all DYMO routers in a DYMO MANET network are connected to a single subnet? I'm tempted to think so... could you please clarify? >>> MsgHdr.HopCnt The number of hops this message has traversed. >> >> Why is there a need of this field when the Hop Limit in the IP >> header does the same thing? > > Messages are not forwarded by native IP forwarding. They are > received, processed, and then resulting LL messages might be sent. > The MsgHdr.HopLimit controls dissemination via this mechanism. I really am not sure what you mean... In a sense you seem to say that the whole MANET network is one subnet (no packets forwarded over multiple hops) and in another sense you say there are HopLimit variables... I'll have to read it. >>> AddBlk.TargetNode.Address The IP address of the message >>> TargetNode. In a RREQ the TargetNode is the destination for which >>> a forwarding route does not exist and route discovery is being >>> performed. In a RREP the target node is the RREQ OrigNode. The >>> TargetNode address is the first address in the routing message. >> >> Why is the TargetNode address necessary in the RREP when the IP dst >> field contains the same thing? > > In a RREP the IP destination does not contain the same thing. The IP > destination is the next hop router's address toward the RREP target. > I don't understand... but I'll have to read more. >>> 5.7. Advertising Network Addresses >>> >>> Any node can advertise a network address by using a PREFIX_LENGTH >>> TLV [I-D.ietf-manet-packetbb]. Any nodes (other than the >>> advertising node) within the advertised prefix SHOULD NOT >>> participate in the DYMO protocol directly and these nodes MUST be >>> reachable by forwarding packets to the node advertising >>> connectivity. Nodes other than the advertising node that do >>> participate in DYMO must forward the DYMO control packets to the >>> advertising node. For example, A.B.C.1 with a prefix length of >>> 24 indicates all nodes with the matching A.B.C.X are reachable >>> through the node with address A.B.C.1. >> >> Ok, but does MANET Router send Router Advertisements? > > Router advertisements are not DYMO routing protocol messages. Router > advertisements are generally for nodes attached to routers, not > router to router routing protocol communication. Generally yes, I agree. However, in a MANEMO context, the Mobile Router acts a bit as a host on its egress interface and configures a default route and a CoA based on the RA received from another router. If a DYMO router doesn't send RAs then a MANEMO MR can't configure a default route from it. The DYMO spec doesn't seem to care about default routes. Probably there is a reason for that, good to use in a DYMO MANET network. But in a MANEMO or NEMO moving network there _are_ default routes and they are needed. I think I tend to disgress this dicussion towards the MANEMO needs, and away from MANET protocol design for DYMO requirements. I think my interest is mainly in MANEMO context. >>> While DYMO does not place restrictions on the authentication >>> mechanism used for this purpose, IPsec Authentication Message >>> (AH) is an appropriate choice for cases where the nodes share an >>> appropriate security association that enables the use of AH. >> >> How about recommending IPsec ESP too? > > This is an option, but generally authentication is the most important > component. I agree. >>> If the mobile nodes in the ad hoc network have pre-established >>> security associations, the purposes for which the security >>> associations are created should include that of authorizing the >>> processing of DYMO control packets. Given this understanding, >>> the mobile nodes should be able to use the same authentication >>> mechanisms based on their IP addresses as they would have used >>> otherwise. >> >> And if the mobile nodes in the ad hoc network _don't_ have >> pre-established security associations? > > I believe this falls in the research arena. Well, depends. Using certificates (instead of pre-established security associations) and/or IKE is spec'ed in RFCs Standards Tracks I believe. MIP6 Return Routability messages are also RFC Std Track. These two I can think of quickly as not using pre-established SAs. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 08:51:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvC2G-0001Kj-Mf; Mon, 04 Jun 2007 08:51:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvC2F-0001Kb-0r for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 08:51:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvC2E-0001KT-Nd for manet@ietf.org; Mon, 04 Jun 2007 08:51:46 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvC2D-0005Jx-Vq for manet@ietf.org; Mon, 04 Jun 2007 08:51:46 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1931296ugc for ; Mon, 04 Jun 2007 05:51:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QvHDnoHt5KQgboUWBg01iwjqrZ7LZ3YmuE/qfQJAco5VisYOGfx+i8VvH/wnNr8MbLYg8FYRfrjpiAL8XHF2JSRAhzD3Q2/rksQOgSeJdOkJLTO6AIHlF1D84GtF6ji1W8Q/yP1dp86rpFkVKYGYN3LFvuD9QJ6/1wzuJYKHjAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RhYf/GROmKU65EC2UjcMWLd1XMnF1KQF+OoaFYhEoZmXoPhguPY0j3A56rDjCw8sgvyG/hEy/uoy42T6IpTguqU8pHHo2EaKLfjqg8MKQpXDwLNsomDuqVF3KV2NgmqkZ6TUExZo2Kvl1N5GdSsJib/4maOQ57d4rgPkwcUas4M= Received: by 10.78.193.19 with SMTP id q19mr1952644huf.1180961504552; Mon, 04 Jun 2007 05:51:44 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 4 Jun 2007 05:51:44 -0700 (PDT) Message-ID: <374005f30706040551s34c31c97k7e71588898b08aca@mail.gmail.com> Date: Mon, 4 Jun 2007 18:21:44 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Comments on DYMO In-Reply-To: <46640066.90907@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> <374005f30706020454p6a65c2bcw141937e732038fa0@mail.gmail.com> <46640066.90907@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org """When a source's DYMO router needs to forward a data packet and it does not have a ...""" I've also updated other places, where the source's router needs to perform operations on behalf of nodes in its prefix(es). Ian On 6/4/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > Alexandru, > > > > I now understand your query about sources having to be DYMO routers. I > > have updated the text in relation to this issue. The text in the next > > revision will make it clear that the source's DYMO router is > > responsible for initiating route discovery on its behalf. > > Hi Ian, what does the text look like? > > Alex > > > > > Ian > > > > On 6/2/07, Ian Chakeres wrote: > >> Comments inline. > >> > >> On 6/1/07, Alexandru Petrescu wrote: > >> > Hi, some of these comments were raised previously I believe. > >> > > >> > DYMO is in draft-ietf-manet-dymo-09.txt > >> > > >> > > Most DYMO messages are sent with the IP destination address set to > >> > > the link-local multicast address LL MANET ROUTERS unless otherwise > >> > > stated. Unicast DYMO messages specified in this document are sent > >> > > with the IP destination set to the Route.NextHopAddress of the route > >> > > to the TargetNode. > >> > > >> > RREQs are specified to be sent to a LL multicast address, but nodes > >> > are not required to join that group - they should, and probably better > >> > with MLD and IGMP. > >> > >> I will put that DYMO routers should subscribe to the LL multicast > >> group. I'm a little unclear about MLD/IGMP comment, since there is no > >> need to inform anyone about LL subscriptions. > >> > >> > > When a node originates a data packet and does not have a forwarding > >> > > route to the IP.DestinationAddress, it sends a RREQ (described in > >> > > Section 5.3.1) to discover a route to the particular destination > >> > > (TargetNode). > >> > > >> > Apparently the application must run on the router that initiates the > >> > RREQ. Ie it is not possible to have an LFN behind an MR because MR > >> > doesn't know when to send the RREQ. With NEMO moving networks the LFN > >> > (Local Fixed Node) is a vanilla stack host not doing any mobility nor > >> > much dynamic routing. > >> > >> A DYMO router can be responsible for prefixes of attached hosts. In > >> this case the router manages the sequence number space for the sources > >> in the prefixes. I thought this concept was captured in Section 5.7 > >> that you mention below. Perhaps it should be made more explicit. Would > >> you suggest I expand that section or flush it out more in the text > >> directly? > >> > >> > Another question that comes to mind is how does a DYMO router discover > >> > its neighbor routers? Apparently DYMO doesn't specify anything for > >> > this. I think ND rfc2461 should be used for that purpose. > >> > >> DYMO "discovers" other neighboring routers by the reception of RM. An > >> alternative and more robust mechanism like NHDP could and probably > >> should be used in most deployments. > >> > >> > > The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) > >> > > for all messages specified in this document. > >> > > >> > 1? Then the DYMO messages are discarded when crossing another router? > >> > Or is the entire MANET a single subnet? > >> > >> All packets are LL, there are no packets that are forwarded over > >> multiple hops. > >> > >> > > IP.DestinationAddress The IP address of the packet destination. For > >> > > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For RREP > >> > > the IP.DestinationAddress is set to the NextHopAddress toward the > >> > > TargetNode. > >> > > >> > So all MANET routers must join the LL MANET routers address - is this > >> > specified? > >> > > >> > > MsgHdr.HopCnt The number of hops this message has traversed. > >> > > >> > Why is there a need of this field when the Hop Limit in the IP header > >> > does the same thing? > >> > >> Messages are not forwarded by native IP forwarding. They are received, > >> processed, and then resulting LL messages might be sent. The > >> MsgHdr.HopLimit controls dissemination via this mechanism. > >> > >> > > AddBlk.TargetNode.Address The IP address of the message TargetNode. > >> > > In a RREQ the TargetNode is the destination for which a forwarding > >> > > route does not exist and route discovery is being performed. In a > >> > > RREP the target node is the RREQ OrigNode. The TargetNode address is > >> > > the first address in the routing message. > >> > > >> > Why is the TargetNode address necessary in the RREP when the IP dst > >> > field contains the same thing? > >> > >> In a RREP the IP destination does not contain the same thing. The IP > >> destination is the next hop router's address toward the RREP target. > >> > >> > > AddBlk.OrigNode.Address The IP address of the OrigNode. This address > >> > > is in an address block and not in the message header to allow for > >> > > address compression and additional AddTLVs. This address is the > >> > > second address in the message for RREQ. > >> > > >> > Why is this here when the src field has it too? > >> > > >> > > The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ > >> > > TargetNode, so that the RREQ TargetNode receives routing information > >> > > on how to reach the RREQ OrigNode. > >> > > >> > But a gratuitous message is sent without receiving any message (no RREQ > >> > received), so how does the intermediate node know the RREQ TargetNode? > >> > > >> > > Before processing a RM, a node checks the IP.Destination to ensure > >> > > that it is a link-local packet. > >> > > >> > Only 'link-local'? We know (by this spec) that the dst address can be > >> > a ll multicast address or a unicast address. If the unicast address > >> > can only have a ll scope (fe80) then the entire MANET can only be a > >> > single subnet? > >> > > >> > > 5.7. Advertising Network Addresses > >> > > > >> > > Any node can advertise a network address by using a PREFIX_LENGTH TLV > >> > > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising > >> > > node) within the advertised prefix SHOULD NOT participate in the DYMO > >> > > protocol directly and these nodes MUST be reachable by forwarding > >> > > packets to the node advertising connectivity. Nodes other than the > >> > > advertising node that do participate in DYMO must forward the DYMO > >> > > control packets to the advertising node. For example, A.B.C.1 with a > >> > > prefix length of 24 indicates all nodes with the matching A.B.C.X > >> > > are reachable through the node with address A.B.C.1. > >> > > >> > Ok, but does MANET Router send Router Advertisements? > >> > >> Router advertisements are not DYMO routing protocol messages. Router > >> advertisements are generally for nodes attached to routers, not router > >> to router routing protocol communication. > >> > >> > > 8. Security Considerations > >> > > > >> > > Currently, DYMO does not specify any special security measures. > >> > > Routing protocols, however, are prime targets for impersonation > >> > > attacks. In networks where the node membership is not known, it is > >> > > difficult to determine the occurrence of impersonation attacks, and > >> > > security prevention techniques are difficult at best. However, when > >> > > the network membership is known and there is a danger of such attacks > >> > > >> > What is 'node membership'? > >> > >> A priori knowledge of the different routers that a particular router > >> will communicate with in the future. > >> > >> > > While DYMO does not place restrictions on the authentication > >> > > mechanism used for this purpose, IPsec Authentication Message (AH) is > >> > > an appropriate choice for cases where the nodes share an appropriate > >> > > security association that enables the use of AH. > >> > > >> > How about recommending IPsec ESP too? > >> > >> This is an option, but generally authentication is the most important > >> component. > >> > >> > > If the mobile nodes in the ad hoc network have pre-established > >> > > security associations, the purposes for which the security > >> > > associations are created should include that of authorizing the > >> > > processing of DYMO control packets. Given this understanding, the > >> > > mobile nodes should be able to use the same authentication mechanisms > >> > > based on their IP addresses as they would have used otherwise. > >> > > >> > And if the mobile nodes in the ad hoc network _don't_ have > >> > pre-established security associations? > >> > >> I believe this falls in the research arena. > >> > >> > This case is very important for MANEMO types of deployments where NEMO > >> > moving networks come and go. > >> > > >> > Alex > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs Email Security System. > >> > For more information please visit http://www.messagelabs.com/email > >> > ______________________________________________________________________ > >> > > >> > > >> > _______________________________________________ > >> > manet mailing list > >> > manet@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/manet > >> > > >> > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 09:11:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCJx-0002AK-QB; Mon, 04 Jun 2007 09:10:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvCJw-00029y-Ii for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 09:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCJw-00029q-94 for manet@ietf.org; Mon, 04 Jun 2007 09:10:04 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvCJv-00085T-Ht for manet@ietf.org; Mon, 04 Jun 2007 09:10:04 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1941713ugc for ; Mon, 04 Jun 2007 06:10:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WLtOe0leF3Pd50oWlDCMdMCyQYJ+2Xf/Ec7kXPOWpSidJofwzQqir/dQHAaWV54RMt01zon0wo8Gab7QJ9a7uEdXRd8jKMwyNKGTuTpge4jPlhUvzGpn5PV9n+Y1njM23jQ7k3zrjOgHssUoV8RXK+OZ10ZNYHzJZRX6xbX+Hf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C9UZAhp5J0jdvvYRTNgAYxnmrzxJfeZCUXfToBrgfdJ32/fuecJ76T02Ny9oESI/zSuA7DEX4SO10oYC4Z3MU5h3ghyWEny9ANWxK10nVjH08b02iZo4CnJd5i9RGbFfkszT2twcurnkofinTi1Zsm53oOPKeTzyejWERPQEsno= Received: by 10.78.56.19 with SMTP id e19mr1956489hua.1180962602334; Mon, 04 Jun 2007 06:10:02 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 4 Jun 2007 06:10:02 -0700 (PDT) Message-ID: <374005f30706040610h437921ddjc9e9d4f20e539a75@mail.gmail.com> Date: Mon, 4 Jun 2007 18:40:02 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Comments on DYMO In-Reply-To: <466406C3.60603@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> <466406C3.60603@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 6/4/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > Comments inline. > > > > On 6/1/07, Alexandru Petrescu wrote: > >> Hi, some of these comments were raised previously I believe. > >> > >> DYMO is in draft-ietf-manet-dymo-09.txt > >> > >>> Most DYMO messages are sent with the IP destination address set > >>> to the link-local multicast address LL MANET ROUTERS unless > >>> otherwise stated. Unicast DYMO messages specified in this > >>> document are sent with the IP destination set to the > >>> Route.NextHopAddress of the route to the TargetNode. > >> > >> RREQs are specified to be sent to a LL multicast address, but nodes > >> are not required to join that group - they should, and probably > >> better with MLD and IGMP. > > > > I will put that DYMO routers should subscribe to the LL multicast > > group. I'm a little unclear about MLD/IGMP comment, since there is no > > need to inform anyone about LL subscriptions. > > I'm not sure why you say there is no need to inform anyone about LL > subscriptions? I think only the routers that subscribed to that group > should receive the DYMO Routing Message. This is achieved by sending a > message saying it's interested in that group. Then the DYMO RMs are > sent only to the routers interested in, bandwidth is saved. Especially in MANET, nodes may not know if people are interested all the time. They should send them anyway. I think it also depends on IPv4/IPv6 about the issuance of IGMP messages related to LL multicast groups. I will add text to state that DYMO routers should subscribe to LL MANET routers. > >>> When a node originates a data packet and does not have a > >>> forwarding route to the IP.DestinationAddress, it sends a RREQ > >>> (described in Section 5.3.1) to discover a route to the > >>> particular destination (TargetNode). > >> > >> Apparently the application must run on the router that initiates > >> the RREQ. Ie it is not possible to have an LFN behind an MR > >> because MR doesn't know when to send the RREQ. With NEMO moving > >> networks the LFN (Local Fixed Node) is a vanilla stack host not > >> doing any mobility nor much dynamic routing. > > > > A DYMO router can be responsible for prefixes of attached hosts. > > In a MANEMO topology the Mobile Router (presumably the DYMO router) is > routing not only for hosts directly attached to it but also for all > other hosts in the NEMO moving network (presumably separated from it by > Fixed Routers). The prefixes of the directly attached hosts and of the > hosts attached on FR can be completely different (not aggregated). > > So a DYMO router, if it wants to send RREQ to other DYMO routers it > should do so for all hosts directly or indirectly (through FR) attached > to it, ie hosts in the NEMO moving network. > > The DYMO sourter, if it wants to send RREP when requested by other DYMO > routers, should send RREP containing not only the prefix of its directly > attached hosts but also the prefixes of hosts that can be attached on > the Fixed Router. This sounds fine. > > In this case the router manages the sequence number space for the > > sources in the prefixes. I thought this concept was captured in > > Section 5.7 that you mention below. Perhaps it should be made more > > explicit. Would you suggest I expand that section or flush it out > > more in the text directly? > > Sorry, I don't yet have a full understanding of DYMO sequence numbers. > I'll have to see this. > > >> Another question that comes to mind is how does a DYMO router > >> discover its neighbor routers? Apparently DYMO doesn't specify > >> anything for this. I think ND rfc2461 should be used for that > >> purpose. > > > > DYMO "discovers" other neighboring routers by the reception of RM. > > Wouldn't it be more flexible if discovering was allowed too by the > reception of periodic unsolicited advertisements? Like hosts discover > routers by either receiving unsolicitied advertisements or > 'pro-actively' requesting one? > > I think yes IMHO. DYMO does not disallow this behavior, but it does not mandate it either. > > An alternative and more robust mechanism like NHDP could and probably > > should be used in most deployments. > > There are more ND deployments than NHDP thus ND would be better I believe. ND does not handle asymmetric reachability. Also it cannot be combined with other MANET messaging. This is not to say, that ND could not be useful in addition to other mechanisms. > >>> The IP TTL (IP Hop Limit) field for DYMO messages is set to one > >>> (1) for all messages specified in this document. > >> > >> 1? Then the DYMO messages are discarded when crossing another > >> router? Or is the entire MANET a single subnet? > > > > All packets are LL, there are no packets that are forwarded over > > multiple hops. > > Does this mean that all DYMO routers in a DYMO MANET network are > connected to a single subnet? I'm tempted to think so... could you > please clarify? Subnet is a poorly defined term. Please see the MANET arch document about addressing. I will say that if one DYMO router sends a LL multicast, it does not expect to reach all other DYMO routers in a MANET. I will say that all DYMO routers in a MANET are expected to be within one IP hop of another DYMO router. > >>> MsgHdr.HopCnt The number of hops this message has traversed. > >> > >> Why is there a need of this field when the Hop Limit in the IP > >> header does the same thing? > > > > Messages are not forwarded by native IP forwarding. They are > > received, processed, and then resulting LL messages might be sent. > > The MsgHdr.HopLimit controls dissemination via this mechanism. > > I really am not sure what you mean... > > In a sense you seem to say that the whole MANET network is one subnet > (no packets forwarded over multiple hops) and in another sense you say > there are HopLimit variables... No packets are forwarded over multiple hops. Instead the appropriate information is placed in a new packet. In this way information is propagated over multiple hops. > I'll have to read it. > > >>> AddBlk.TargetNode.Address The IP address of the message > >>> TargetNode. In a RREQ the TargetNode is the destination for which > >>> a forwarding route does not exist and route discovery is being > >>> performed. In a RREP the target node is the RREQ OrigNode. The > >>> TargetNode address is the first address in the routing message. > >> > >> Why is the TargetNode address necessary in the RREP when the IP dst > >> field contains the same thing? > > > > In a RREP the IP destination does not contain the same thing. The IP > > destination is the next hop router's address toward the RREP target. > > > I don't understand... but I'll have to read more. > > >>> 5.7. Advertising Network Addresses > >>> > >>> Any node can advertise a network address by using a PREFIX_LENGTH > >>> TLV [I-D.ietf-manet-packetbb]. Any nodes (other than the > >>> advertising node) within the advertised prefix SHOULD NOT > >>> participate in the DYMO protocol directly and these nodes MUST be > >>> reachable by forwarding packets to the node advertising > >>> connectivity. Nodes other than the advertising node that do > >>> participate in DYMO must forward the DYMO control packets to the > >>> advertising node. For example, A.B.C.1 with a prefix length of > >>> 24 indicates all nodes with the matching A.B.C.X are reachable > >>> through the node with address A.B.C.1. > >> > >> Ok, but does MANET Router send Router Advertisements? > > > > Router advertisements are not DYMO routing protocol messages. Router > > advertisements are generally for nodes attached to routers, not > > router to router routing protocol communication. > > Generally yes, I agree. > > However, in a MANEMO context, the Mobile Router acts a bit as a host on > its egress interface and configures a default route and a CoA based on > the RA received from another router. > > If a DYMO router doesn't send RAs then a MANEMO MR can't configure a > default route from it. A (DYMO) router could easily send RAs on its classic IP interfaces (see manetarch - figure 1 i think - nodes behind the router). > The DYMO spec doesn't seem to care about default routes. Probably there > is a reason for that, good to use in a DYMO MANET network. > > But in a MANEMO or NEMO moving network there _are_ default routes and > they are needed. > > I think I tend to disgress this dicussion towards the MANEMO needs, and > away from MANET protocol design for DYMO requirements. I think my > interest is mainly in MANEMO context. > > >>> While DYMO does not place restrictions on the authentication > >>> mechanism used for this purpose, IPsec Authentication Message > >>> (AH) is an appropriate choice for cases where the nodes share an > >>> appropriate security association that enables the use of AH. > >> > >> How about recommending IPsec ESP too? > > > > This is an option, but generally authentication is the most important > > component. > > I agree. > > >>> If the mobile nodes in the ad hoc network have pre-established > >>> security associations, the purposes for which the security > >>> associations are created should include that of authorizing the > >>> processing of DYMO control packets. Given this understanding, > >>> the mobile nodes should be able to use the same authentication > >>> mechanisms based on their IP addresses as they would have used > >>> otherwise. > >> > >> And if the mobile nodes in the ad hoc network _don't_ have > >> pre-established security associations? > > > > I believe this falls in the research arena. > > Well, depends. Using certificates (instead of pre-established security > associations) and/or IKE is spec'ed in RFCs Standards Tracks I believe. > MIP6 Return Routability messages are also RFC Std Track. These two I > can think of quickly as not using pre-established SAs. I agree certs could be used. My point was that something needs to be pre-established (not necessarily SAs). Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 09:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCmx-0000Bv-7x; Mon, 04 Jun 2007 09:40:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvCmv-0000Bg-8M for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 09:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCmu-0000BY-Uq for manet@ietf.org; Mon, 04 Jun 2007 09:40:00 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvCmu-00063A-Fj for manet@ietf.org; Mon, 04 Jun 2007 09:40:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1180964399!17937883!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 1940 invoked from network); 4 Jun 2007 13:39:59 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-11.tower-119.messagelabs.com with SMTP; 4 Jun 2007 13:39:59 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l54Ddxft000403; Mon, 4 Jun 2007 06:39:59 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l54DdwHu009098; Mon, 4 Jun 2007 08:39:58 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l54Ddufl009072; Mon, 4 Jun 2007 08:39:57 -0500 (CDT) Message-ID: <4664162C.1030600@gmail.com> Date: Mon, 04 Jun 2007 15:39:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Comments on DYMO References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> <374005f30706020454p6a65c2bcw141937e732038fa0@mail.gmail.com> <46640066.90907@gmail.com> <374005f30706040551s34c31c97k7e71588898b08aca@mail.gmail.com> In-Reply-To: <374005f30706040551s34c31c97k7e71588898b08aca@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > """When a source's DYMO router needs to forward a data packet and it > does not have a ...""" And what if it has a default route? Alex > > I've also updated other places, where the source's router needs to > perform operations on behalf of nodes in its prefix(es). > > Ian > > On 6/4/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >> > Alexandru, >> > >> > I now understand your query about sources having to be DYMO routers. I >> > have updated the text in relation to this issue. The text in the next >> > revision will make it clear that the source's DYMO router is >> > responsible for initiating route discovery on its behalf. >> >> Hi Ian, what does the text look like? >> >> Alex >> >> > >> > Ian >> > >> > On 6/2/07, Ian Chakeres wrote: >> >> Comments inline. >> >> >> >> On 6/1/07, Alexandru Petrescu wrote: >> >> > Hi, some of these comments were raised previously I believe. >> >> > >> >> > DYMO is in draft-ietf-manet-dymo-09.txt >> >> > >> >> > > Most DYMO messages are sent with the IP destination address set to >> >> > > the link-local multicast address LL MANET ROUTERS unless otherwise >> >> > > stated. Unicast DYMO messages specified in this document are sent >> >> > > with the IP destination set to the Route.NextHopAddress of the >> route >> >> > > to the TargetNode. >> >> > >> >> > RREQs are specified to be sent to a LL multicast address, but nodes >> >> > are not required to join that group - they should, and probably >> better >> >> > with MLD and IGMP. >> >> >> >> I will put that DYMO routers should subscribe to the LL multicast >> >> group. I'm a little unclear about MLD/IGMP comment, since there is no >> >> need to inform anyone about LL subscriptions. >> >> >> >> > > When a node originates a data packet and does not have a >> forwarding >> >> > > route to the IP.DestinationAddress, it sends a RREQ (described in >> >> > > Section 5.3.1) to discover a route to the particular destination >> >> > > (TargetNode). >> >> > >> >> > Apparently the application must run on the router that initiates the >> >> > RREQ. Ie it is not possible to have an LFN behind an MR because MR >> >> > doesn't know when to send the RREQ. With NEMO moving networks >> the LFN >> >> > (Local Fixed Node) is a vanilla stack host not doing any mobility >> nor >> >> > much dynamic routing. >> >> >> >> A DYMO router can be responsible for prefixes of attached hosts. In >> >> this case the router manages the sequence number space for the sources >> >> in the prefixes. I thought this concept was captured in Section 5.7 >> >> that you mention below. Perhaps it should be made more explicit. Would >> >> you suggest I expand that section or flush it out more in the text >> >> directly? >> >> >> >> > Another question that comes to mind is how does a DYMO router >> discover >> >> > its neighbor routers? Apparently DYMO doesn't specify anything for >> >> > this. I think ND rfc2461 should be used for that purpose. >> >> >> >> DYMO "discovers" other neighboring routers by the reception of RM. An >> >> alternative and more robust mechanism like NHDP could and probably >> >> should be used in most deployments. >> >> >> >> > > The IP TTL (IP Hop Limit) field for DYMO messages is set to one >> (1) >> >> > > for all messages specified in this document. >> >> > >> >> > 1? Then the DYMO messages are discarded when crossing another >> router? >> >> > Or is the entire MANET a single subnet? >> >> >> >> All packets are LL, there are no packets that are forwarded over >> >> multiple hops. >> >> >> >> > > IP.DestinationAddress The IP address of the packet >> destination. For >> >> > > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For >> RREP >> >> > > the IP.DestinationAddress is set to the NextHopAddress toward the >> >> > > TargetNode. >> >> > >> >> > So all MANET routers must join the LL MANET routers address - is >> this >> >> > specified? >> >> > >> >> > > MsgHdr.HopCnt The number of hops this message has traversed. >> >> > >> >> > Why is there a need of this field when the Hop Limit in the IP >> header >> >> > does the same thing? >> >> >> >> Messages are not forwarded by native IP forwarding. They are received, >> >> processed, and then resulting LL messages might be sent. The >> >> MsgHdr.HopLimit controls dissemination via this mechanism. >> >> >> >> > > AddBlk.TargetNode.Address The IP address of the message >> TargetNode. >> >> > > In a RREQ the TargetNode is the destination for which a forwarding >> >> > > route does not exist and route discovery is being performed. In a >> >> > > RREP the target node is the RREQ OrigNode. The TargetNode >> address is >> >> > > the first address in the routing message. >> >> > >> >> > Why is the TargetNode address necessary in the RREP when the IP dst >> >> > field contains the same thing? >> >> >> >> In a RREP the IP destination does not contain the same thing. The IP >> >> destination is the next hop router's address toward the RREP target. >> >> >> >> > > AddBlk.OrigNode.Address The IP address of the OrigNode. This >> address >> >> > > is in an address block and not in the message header to allow for >> >> > > address compression and additional AddTLVs. This address is the >> >> > > second address in the message for RREQ. >> >> > >> >> > Why is this here when the src field has it too? >> >> > >> >> > > The Intermediate Node SHOULD also issue a gratuitous RREP to >> the RREQ >> >> > > TargetNode, so that the RREQ TargetNode receives routing >> information >> >> > > on how to reach the RREQ OrigNode. >> >> > >> >> > But a gratuitous message is sent without receiving any message >> (no RREQ >> >> > received), so how does the intermediate node know the RREQ >> TargetNode? >> >> > >> >> > > Before processing a RM, a node checks the IP.Destination to ensure >> >> > > that it is a link-local packet. >> >> > >> >> > Only 'link-local'? We know (by this spec) that the dst address >> can be >> >> > a ll multicast address or a unicast address. If the unicast address >> >> > can only have a ll scope (fe80) then the entire MANET can only be a >> >> > single subnet? >> >> > >> >> > > 5.7. Advertising Network Addresses >> >> > > >> >> > > Any node can advertise a network address by using a >> PREFIX_LENGTH TLV >> >> > > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising >> >> > > node) within the advertised prefix SHOULD NOT participate in >> the DYMO >> >> > > protocol directly and these nodes MUST be reachable by forwarding >> >> > > packets to the node advertising connectivity. Nodes other than >> the >> >> > > advertising node that do participate in DYMO must forward the DYMO >> >> > > control packets to the advertising node. For example, A.B.C.1 >> with a >> >> > > prefix length of 24 indicates all nodes with the matching A.B.C.X >> >> > > are reachable through the node with address A.B.C.1. >> >> > >> >> > Ok, but does MANET Router send Router Advertisements? >> >> >> >> Router advertisements are not DYMO routing protocol messages. Router >> >> advertisements are generally for nodes attached to routers, not router >> >> to router routing protocol communication. >> >> >> >> > > 8. Security Considerations >> >> > > >> >> > > Currently, DYMO does not specify any special security measures. >> >> > > Routing protocols, however, are prime targets for impersonation >> >> > > attacks. In networks where the node membership is not known, >> it is >> >> > > difficult to determine the occurrence of impersonation attacks, >> and >> >> > > security prevention techniques are difficult at best. However, >> when >> >> > > the network membership is known and there is a danger of such >> attacks >> >> > >> >> > What is 'node membership'? >> >> >> >> A priori knowledge of the different routers that a particular router >> >> will communicate with in the future. >> >> >> >> > > While DYMO does not place restrictions on the authentication >> >> > > mechanism used for this purpose, IPsec Authentication Message >> (AH) is >> >> > > an appropriate choice for cases where the nodes share an >> appropriate >> >> > > security association that enables the use of AH. >> >> > >> >> > How about recommending IPsec ESP too? >> >> >> >> This is an option, but generally authentication is the most important >> >> component. >> >> >> >> > > If the mobile nodes in the ad hoc network have pre-established >> >> > > security associations, the purposes for which the security >> >> > > associations are created should include that of authorizing the >> >> > > processing of DYMO control packets. Given this understanding, the >> >> > > mobile nodes should be able to use the same authentication >> mechanisms >> >> > > based on their IP addresses as they would have used otherwise. >> >> > >> >> > And if the mobile nodes in the ad hoc network _don't_ have >> >> > pre-established security associations? >> >> >> >> I believe this falls in the research arena. >> >> >> >> > This case is very important for MANEMO types of deployments where >> NEMO >> >> > moving networks come and go. >> >> > >> >> > Alex >> >> > >> >> > >> ______________________________________________________________________ >> >> > This email has been scanned by the MessageLabs Email Security >> System. >> >> > For more information please visit http://www.messagelabs.com/email >> >> > >> ______________________________________________________________________ >> >> > >> >> > >> >> > _______________________________________________ >> >> > manet mailing list >> >> > manet@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/manet >> >> > >> >> >> > >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 09:51:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCxY-0008LJ-H2; Mon, 04 Jun 2007 09:51:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvCxW-0008LE-Dr for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 09:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCxW-0008L2-47 for manet@ietf.org; Mon, 04 Jun 2007 09:50:58 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvCxV-0007Qc-JE for manet@ietf.org; Mon, 04 Jun 2007 09:50:58 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1180965056!6641700!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13730 invoked from network); 4 Jun 2007 13:50:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 4 Jun 2007 13:50:56 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54DouU5014269; Mon, 4 Jun 2007 06:50:56 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l54DotjL022610; Mon, 4 Jun 2007 08:50:55 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l54DosDR022583; Mon, 4 Jun 2007 08:50:54 -0500 (CDT) Message-ID: <466418BD.5010507@gmail.com> Date: Mon, 04 Jun 2007 15:50:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Comments on DYMO References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> <466406C3.60603@gmail.com> <374005f30706040610h437921ddjc9e9d4f20e539a75@mail.gmail.com> In-Reply-To: <374005f30706040610h437921ddjc9e9d4f20e539a75@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Comments inline. > > On 6/4/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >>> Comments inline. >>> >>> On 6/1/07, Alexandru Petrescu >>> wrote: >>>> Hi, some of these comments were raised previously I believe. >>>> >>>> DYMO is in draft-ietf-manet-dymo-09.txt >>>> >>>>> Most DYMO messages are sent with the IP destination address >>>>> set to the link-local multicast address LL MANET ROUTERS >>>>> unless otherwise stated. Unicast DYMO messages specified in >>>>> this document are sent with the IP destination set to the >>>>> Route.NextHopAddress of the route to the TargetNode. >>>> >>>> RREQs are specified to be sent to a LL multicast address, but >>>> nodes are not required to join that group - they should, and >>>> probably better with MLD and IGMP. >>> >>> I will put that DYMO routers should subscribe to the LL multicast >>> group. I'm a little unclear about MLD/IGMP comment, since there >>> is no need to inform anyone about LL subscriptions. >> >> I'm not sure why you say there is no need to inform anyone about LL >> subscriptions? I think only the routers that subscribed to that >> group should receive the DYMO Routing Message. This is achieved by >> sending a message saying it's interested in that group. Then the >> DYMO RMs are sent only to the routers interested in, bandwidth is >> saved. > > Especially in MANET, nodes may not know if people are interested all > the time. They should send them anyway. > > I think it also depends on IPv4/IPv6 about the issuance of IGMP > messages related to LL multicast groups. > > I will add text to state that DYMO routers should subscribe to LL > MANET routers. > >>>>> When a node originates a data packet and does not have a >>>>> forwarding route to the IP.DestinationAddress, it sends a >>>>> RREQ (described in Section 5.3.1) to discover a route to the >>>>> particular destination (TargetNode). >>>> >>>> Apparently the application must run on the router that >>>> initiates the RREQ. Ie it is not possible to have an LFN >>>> behind an MR because MR doesn't know when to send the RREQ. >>>> With NEMO moving networks the LFN (Local Fixed Node) is a >>>> vanilla stack host not doing any mobility nor much dynamic >>>> routing. >>> >>> A DYMO router can be responsible for prefixes of attached hosts. >> >> In a MANEMO topology the Mobile Router (presumably the DYMO router) >> is routing not only for hosts directly attached to it but also for >> all other hosts in the NEMO moving network (presumably separated >> from it by Fixed Routers). The prefixes of the directly attached >> hosts and of the hosts attached on FR can be completely different >> (not aggregated). >> >> So a DYMO router, if it wants to send RREQ to other DYMO routers it >> should do so for all hosts directly or indirectly (through FR) >> attached to it, ie hosts in the NEMO moving network. >> >> The DYMO sourter, if it wants to send RREP when requested by other >> DYMO routers, should send RREP containing not only the prefix of >> its directly attached hosts but also the prefixes of hosts that can >> be attached on the Fixed Router. > > This sounds fine. > >>> In this case the router manages the sequence number space for the >>> sources in the prefixes. I thought this concept was captured in >>> Section 5.7 that you mention below. Perhaps it should be made >>> more explicit. Would you suggest I expand that section or flush >>> it out more in the text directly? >> >> Sorry, I don't yet have a full understanding of DYMO sequence >> numbers. I'll have to see this. >> >>>> Another question that comes to mind is how does a DYMO router >>>> discover its neighbor routers? Apparently DYMO doesn't specify >>>> anything for this. I think ND rfc2461 should be used for that >>>> purpose. >>> >>> DYMO "discovers" other neighboring routers by the reception of >>> RM. >> >> Wouldn't it be more flexible if discovering was allowed too by the >> reception of periodic unsolicited advertisements? Like hosts >> discover routers by either receiving unsolicitied advertisements or >> 'pro-actively' requesting one? >> >> I think yes IMHO. > > DYMO does not disallow this behavior, but it does not mandate it > either. > >>> An alternative and more robust mechanism like NHDP could and >>> probably should be used in most deployments. >> >> There are more ND deployments than NHDP thus ND would be better I >> believe. > > ND does not handle asymmetric reachability. Right... UDLR and some TCP flavors do. > Also it cannot be combined with other MANET messaging. > > This is not to say, that ND could not be useful in addition to other > mechanisms. > >>>>> The IP TTL (IP Hop Limit) field for DYMO messages is set to >>>>> one (1) for all messages specified in this document. >>>> >>>> 1? Then the DYMO messages are discarded when crossing another >>>> router? Or is the entire MANET a single subnet? >>> >>> All packets are LL, there are no packets that are forwarded over >>> multiple hops. >> >> Does this mean that all DYMO routers in a DYMO MANET network are >> connected to a single subnet? I'm tempted to think so... could you >> please clarify? > > Subnet is a poorly defined term. Please see the MANET arch document > about addressing. > > I will say that if one DYMO router sends a LL multicast, it does not > expect to reach all other DYMO routers in a MANET. It should expect to reach all the DYMO routers who subscribed that group. > I will say that all DYMO routers in a MANET are expected to be within > one IP hop of another DYMO router. Looks not as routing then :-) This is one link, and link-layer 'routing', no? >>>>> MsgHdr.HopCnt The number of hops this message has traversed. >>>> >>>> Why is there a need of this field when the Hop Limit in the IP >>>> header does the same thing? >>> >>> Messages are not forwarded by native IP forwarding. They are >>> received, processed, and then resulting LL messages might be >>> sent. The MsgHdr.HopLimit controls dissemination via this >>> mechanism. >> >> I really am not sure what you mean... >> >> In a sense you seem to say that the whole MANET network is one >> subnet (no packets forwarded over multiple hops) and in another >> sense you say there are HopLimit variables... > > No packets are forwarded over multiple hops. Instead the appropriate > information is placed in a new packet. In this way information is > propagated over multiple hops. But you said previously that all DYMO routers are within one hop... Sorry... it may be me who doesn't follow all the protocol description. I will stop here asking. I realize much work went into this protocol design. >> Well, depends. Using certificates (instead of pre-established >> security associations) and/or IKE is spec'ed in RFCs Standards >> Tracks I believe. MIP6 Return Routability messages are also RFC Std >> Track. These two I can think of quickly as not using >> pre-established SAs. > > I agree certs could be used. My point was that something needs to be > pre-established (not necessarily SAs). I agree, usually it's the case... just to say that if IKE (and D-H like mechanisms), _or_ certificates and PKI exists, _or_ return routability tests, then nothing is pre-established... and it's not research... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 11:26:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvERd-0003mY-U9; Mon, 04 Jun 2007 11:26:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvERc-0003mK-F0 for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 11:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvERc-0003m7-5H for manet@ietf.org; Mon, 04 Jun 2007 11:26:08 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvERZ-0004jR-Pd for manet@ietf.org; Mon, 04 Jun 2007 11:26:08 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l54FQ4K2024655 for ; Mon, 4 Jun 2007 16:26:04 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l54FQ4RE002017 for ; Mon, 4 Jun 2007 16:26:04 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 04 Jun 2007 16:26:04 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 16:26:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Comments on DYMO Date: Mon, 4 Jun 2007 16:26:03 +0100 Message-ID: In-Reply-To: <466418BD.5010507@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on DYMO Thread-Index: Acemr21SPJ+9gbPQRZWrmvOpQ3OrmAABVYLA From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Ian Chakeres" X-OriginalArrivalTime: 04 Jun 2007 15:26:04.0015 (UTC) FILETIME=[AA0957F0:01C7A6BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >> I will say that if one DYMO router sends a LL multicast, it does not >> expect to reach all other DYMO routers in a MANET. > It should expect to reach all the DYMO routers who subscribed that group. No. Because the LL multicast is only going one hop, and some (usually most) other routers are more than one hop away. >> I will say that all DYMO routers in a MANET are expected to be within >> one IP hop of another DYMO router. > Looks not as routing then :-) This is one link, and link-layer=20 > 'routing', no? No. Each DYMO router is within one hop of another (at least one other) DYMO router, but not of all other DYMO routers. And then you do network layer routing, which is what DYMO is there for. > But you said previously that all DYMO routers are within one hop... See previous comment. Incidentally in these regards, OLSRv2 is the same as DYMO. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 12:00:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEyr-0007Gs-FZ; Mon, 04 Jun 2007 12:00:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvEyW-0006W1-KL for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEyV-0006U2-Un for manet@ietf.org; Mon, 04 Jun 2007 12:00:08 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvEyV-0004VV-Lh for manet@ietf.org; Mon, 04 Jun 2007 12:00:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1180972806!22510873!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23920 invoked from network); 4 Jun 2007 16:00:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 4 Jun 2007 16:00:06 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54G06Vn000637; Mon, 4 Jun 2007 09:00:06 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l54G06xq021839; Mon, 4 Jun 2007 11:00:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l54G04ct021811; Mon, 4 Jun 2007 11:00:05 -0500 (CDT) Message-ID: <46643704.1060805@gmail.com> Date: Mon, 04 Jun 2007 18:00:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Comments on DYMO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >>> I will say that if one DYMO router sends a LL multicast, it does not >>> expect to reach all other DYMO routers in a MANET. > >> It should expect to reach all the DYMO routers who subscribed that > group. > > No. Because the LL multicast is only going one hop, and some > (usually most) other routers are more than one hop away. Ok. >>> I will say that all DYMO routers in a MANET are expected to be within >>> one IP hop of another DYMO router. > >> Looks not as routing then :-) This is one link, and link-layer >> 'routing', no? > > No. Each DYMO router is within one hop of another (at least one > other) DYMO router, but not of all other DYMO routers. And then > you do network layer routing, which is what DYMO is there for. Ok. So this fits Ian's previous explanation where the DYMO's RREQ/RREP IP messages are not 'forwarded' but received, processed and other IP RREQ/RREP constructed and sent. In these messages two variables are used: HopLimit and HopCnt. The base IPv6 header and the IPv4 header have a field called HopLimit and TTL respectively. These fields are used extensively to limit forwarding of packets and keep count of it. DYMO calling HopLimit exactly as Hop Limit in IPv6 base header is a source of confusion to me. DYMO not specifying what to put in the src address of the base header when constructing new messages is confusing to me. I agree with DYMO to use what it sees fit in its messages, especially when it has been experimented in practice. However, that doesn't necessarily make DYMO appropriate for a MANEMO configuration and topology. MANEMO configuration and topologies don't necessarily need the HopLimit field in the UDP payload - it could use the Hop Limit field in the base header. Also, it does not need to 'relay' or 'proxy' messages, it could forward them if need were; such that no need to change neither src nor dst address of base header. MANEMO is the main reason why I post remarks on DYMO. I would invite MANET readers to read MANEMO documents and remark on those too. >> But you said previously that all DYMO routers are within one hop... > > See previous comment. > > Incidentally in these regards, OLSRv2 is the same as DYMO. Thanks for this clarification with respect to OLSRv2 and DYMO behaviour in this respect. That means that OLSRv2 too 'relays' the messages constructing new src and dst addresses in the base header at each hop, right? Alex > > ******************************************************************** > 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 has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 12:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFMw-0000bE-MA; Mon, 04 Jun 2007 12:25:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvFMv-0000aQ-IL for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:25:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFMu-0000Z6-In for manet@ietf.org; Mon, 04 Jun 2007 12:25:21 -0400 Received: from kuber.nabble.com ([216.139.236.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFMt-0007OQ-Am for manet@ietf.org; Mon, 04 Jun 2007 12:25:20 -0400 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1HvFMs-0004Sk-V7 for manet@ietf.org; Mon, 04 Jun 2007 09:25:18 -0700 Message-ID: <10953160.post@talk.nabble.com> Date: Mon, 4 Jun 2007 09:25:18 -0700 (PDT) From: harry2511 To: manet@ietf.org Subject: Re: [manet] GPSR source code In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: harry2511@rediffmail.com References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org hi i am also looking for umts code or model for opnet or for glomosim. if u find this plesae forward this too me too. i need this urgently for my project. thanks Abdelouahid Derhab wrote: >=20 > Hi, >=20 > I am looking for the source code for GPSR routing protocol implemented > under glomosim. Is it possible to get it? >=20 > Thanks in advance. >=20 > Best regards. > Abdelouahid. >=20 > --=20 > Name: Abdelouahid Derhab >=20 > Affiliation: Basic software laboratory, CERIST. >=20 > Address: Rue des 3 fr=C3=A8res A=C3=AFssou Ben Aknoun BP 143 Alger 16030 = Alg=C3=A9rie >=20 > Tel +213 21 91 62 05/08 >=20 > Fax +213 21 91 21 26 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 --=20 View this message in context: http://www.nabble.com/GPSR-source-code-tf3863= 778.html#a10953160 Sent from the IETF - manet mailing list archive at Nabble.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 12:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFRp-0004Lk-W0; Mon, 04 Jun 2007 12:30:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvFRn-0004Im-8x for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFRm-0004HQ-Ur for manet@ietf.org; Mon, 04 Jun 2007 12:30:22 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFRk-0007hT-11 for manet@ietf.org; Mon, 04 Jun 2007 12:30:22 -0400 Received: by ug-out-1314.google.com with SMTP id j30so2105402ugc for ; Mon, 04 Jun 2007 09:30:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aj9QFXv/AiB/Tjw5rNBG6YG2dgdtfDGaKAWUXhUI0B5uGhsjJYLoKUpswNWR3SQSTqAp0sZ0nhKk1upG1pTZjEMT2BvMQa9FvNILQbM5rTNK9w619RoblqiSxtarSi3YXMUTTjItY7KGbE3uE8BEz0z/3fgL967ee1g/3yJv0uQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hmDPHZPwk5QY9aviBciNT6t4760r0hxJ5BSHmDcKiZDM5EXK2Te8Na4bvJDhpMmI6+TcoN9Xws12en9uXA4CEVbdN6dwxm53zrUHJYSoseKrAfxkDWmeaipJoCjhJHlz8DOlLgz67XZ8osbljN+tvR2h8SFl4wDtJAOqNOzkEsw= Received: by 10.78.37.7 with SMTP id k7mr2070440huk.1180974618845; Mon, 04 Jun 2007 09:30:18 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 4 Jun 2007 09:30:18 -0700 (PDT) Message-ID: <374005f30706040930n1a6b4dd6g58ce253cb1b9cedf@mail.gmail.com> Date: Mon, 4 Jun 2007 22:00:18 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Comments on DYMO In-Reply-To: <4664162C.1030600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46601AA5.2050706@gmail.com> <374005f30706020315l79ea45b9s6d02af6d469af3b9@mail.gmail.com> <374005f30706020454p6a65c2bcw141937e732038fa0@mail.gmail.com> <46640066.90907@gmail.com> <374005f30706040551s34c31c97k7e71588898b08aca@mail.gmail.com> <4664162C.1030600@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org If a default route exists in the forwarding table, and the router were not configured to do anything special based on the information in the packet (e.g. src/dst, etc), the packet could be forwarded without performing route discovery. Ian On 6/4/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > """When a source's DYMO router needs to forward a data packet and it > > does not have a ...""" > > And what if it has a default route? > > Alex > > > > > I've also updated other places, where the source's router needs to > > perform operations on behalf of nodes in its prefix(es). > > > > Ian > > > > On 6/4/07, Alexandru Petrescu wrote: > >> Ian Chakeres wrote: > >> > Alexandru, > >> > > >> > I now understand your query about sources having to be DYMO routers. I > >> > have updated the text in relation to this issue. The text in the next > >> > revision will make it clear that the source's DYMO router is > >> > responsible for initiating route discovery on its behalf. > >> > >> Hi Ian, what does the text look like? > >> > >> Alex > >> > >> > > >> > Ian > >> > > >> > On 6/2/07, Ian Chakeres wrote: > >> >> Comments inline. > >> >> > >> >> On 6/1/07, Alexandru Petrescu wrote: > >> >> > Hi, some of these comments were raised previously I believe. > >> >> > > >> >> > DYMO is in draft-ietf-manet-dymo-09.txt > >> >> > > >> >> > > Most DYMO messages are sent with the IP destination address set to > >> >> > > the link-local multicast address LL MANET ROUTERS unless otherwise > >> >> > > stated. Unicast DYMO messages specified in this document are sent > >> >> > > with the IP destination set to the Route.NextHopAddress of the > >> route > >> >> > > to the TargetNode. > >> >> > > >> >> > RREQs are specified to be sent to a LL multicast address, but nodes > >> >> > are not required to join that group - they should, and probably > >> better > >> >> > with MLD and IGMP. > >> >> > >> >> I will put that DYMO routers should subscribe to the LL multicast > >> >> group. I'm a little unclear about MLD/IGMP comment, since there is no > >> >> need to inform anyone about LL subscriptions. > >> >> > >> >> > > When a node originates a data packet and does not have a > >> forwarding > >> >> > > route to the IP.DestinationAddress, it sends a RREQ (described in > >> >> > > Section 5.3.1) to discover a route to the particular destination > >> >> > > (TargetNode). > >> >> > > >> >> > Apparently the application must run on the router that initiates the > >> >> > RREQ. Ie it is not possible to have an LFN behind an MR because MR > >> >> > doesn't know when to send the RREQ. With NEMO moving networks > >> the LFN > >> >> > (Local Fixed Node) is a vanilla stack host not doing any mobility > >> nor > >> >> > much dynamic routing. > >> >> > >> >> A DYMO router can be responsible for prefixes of attached hosts. In > >> >> this case the router manages the sequence number space for the sources > >> >> in the prefixes. I thought this concept was captured in Section 5.7 > >> >> that you mention below. Perhaps it should be made more explicit. Would > >> >> you suggest I expand that section or flush it out more in the text > >> >> directly? > >> >> > >> >> > Another question that comes to mind is how does a DYMO router > >> discover > >> >> > its neighbor routers? Apparently DYMO doesn't specify anything for > >> >> > this. I think ND rfc2461 should be used for that purpose. > >> >> > >> >> DYMO "discovers" other neighboring routers by the reception of RM. An > >> >> alternative and more robust mechanism like NHDP could and probably > >> >> should be used in most deployments. > >> >> > >> >> > > The IP TTL (IP Hop Limit) field for DYMO messages is set to one > >> (1) > >> >> > > for all messages specified in this document. > >> >> > > >> >> > 1? Then the DYMO messages are discarded when crossing another > >> router? > >> >> > Or is the entire MANET a single subnet? > >> >> > >> >> All packets are LL, there are no packets that are forwarded over > >> >> multiple hops. > >> >> > >> >> > > IP.DestinationAddress The IP address of the packet > >> destination. For > >> >> > > RREQ the IP.DestinationAddress is set to LL MANET ROUTERS. For > >> RREP > >> >> > > the IP.DestinationAddress is set to the NextHopAddress toward the > >> >> > > TargetNode. > >> >> > > >> >> > So all MANET routers must join the LL MANET routers address - is > >> this > >> >> > specified? > >> >> > > >> >> > > MsgHdr.HopCnt The number of hops this message has traversed. > >> >> > > >> >> > Why is there a need of this field when the Hop Limit in the IP > >> header > >> >> > does the same thing? > >> >> > >> >> Messages are not forwarded by native IP forwarding. They are received, > >> >> processed, and then resulting LL messages might be sent. The > >> >> MsgHdr.HopLimit controls dissemination via this mechanism. > >> >> > >> >> > > AddBlk.TargetNode.Address The IP address of the message > >> TargetNode. > >> >> > > In a RREQ the TargetNode is the destination for which a forwarding > >> >> > > route does not exist and route discovery is being performed. In a > >> >> > > RREP the target node is the RREQ OrigNode. The TargetNode > >> address is > >> >> > > the first address in the routing message. > >> >> > > >> >> > Why is the TargetNode address necessary in the RREP when the IP dst > >> >> > field contains the same thing? > >> >> > >> >> In a RREP the IP destination does not contain the same thing. The IP > >> >> destination is the next hop router's address toward the RREP target. > >> >> > >> >> > > AddBlk.OrigNode.Address The IP address of the OrigNode. This > >> address > >> >> > > is in an address block and not in the message header to allow for > >> >> > > address compression and additional AddTLVs. This address is the > >> >> > > second address in the message for RREQ. > >> >> > > >> >> > Why is this here when the src field has it too? > >> >> > > >> >> > > The Intermediate Node SHOULD also issue a gratuitous RREP to > >> the RREQ > >> >> > > TargetNode, so that the RREQ TargetNode receives routing > >> information > >> >> > > on how to reach the RREQ OrigNode. > >> >> > > >> >> > But a gratuitous message is sent without receiving any message > >> (no RREQ > >> >> > received), so how does the intermediate node know the RREQ > >> TargetNode? > >> >> > > >> >> > > Before processing a RM, a node checks the IP.Destination to ensure > >> >> > > that it is a link-local packet. > >> >> > > >> >> > Only 'link-local'? We know (by this spec) that the dst address > >> can be > >> >> > a ll multicast address or a unicast address. If the unicast address > >> >> > can only have a ll scope (fe80) then the entire MANET can only be a > >> >> > single subnet? > >> >> > > >> >> > > 5.7. Advertising Network Addresses > >> >> > > > >> >> > > Any node can advertise a network address by using a > >> PREFIX_LENGTH TLV > >> >> > > [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising > >> >> > > node) within the advertised prefix SHOULD NOT participate in > >> the DYMO > >> >> > > protocol directly and these nodes MUST be reachable by forwarding > >> >> > > packets to the node advertising connectivity. Nodes other than > >> the > >> >> > > advertising node that do participate in DYMO must forward the DYMO > >> >> > > control packets to the advertising node. For example, A.B.C.1 > >> with a > >> >> > > prefix length of 24 indicates all nodes with the matching A.B.C.X > >> >> > > are reachable through the node with address A.B.C.1. > >> >> > > >> >> > Ok, but does MANET Router send Router Advertisements? > >> >> > >> >> Router advertisements are not DYMO routing protocol messages. Router > >> >> advertisements are generally for nodes attached to routers, not router > >> >> to router routing protocol communication. > >> >> > >> >> > > 8. Security Considerations > >> >> > > > >> >> > > Currently, DYMO does not specify any special security measures. > >> >> > > Routing protocols, however, are prime targets for impersonation > >> >> > > attacks. In networks where the node membership is not known, > >> it is > >> >> > > difficult to determine the occurrence of impersonation attacks, > >> and > >> >> > > security prevention techniques are difficult at best. However, > >> when > >> >> > > the network membership is known and there is a danger of such > >> attacks > >> >> > > >> >> > What is 'node membership'? > >> >> > >> >> A priori knowledge of the different routers that a particular router > >> >> will communicate with in the future. > >> >> > >> >> > > While DYMO does not place restrictions on the authentication > >> >> > > mechanism used for this purpose, IPsec Authentication Message > >> (AH) is > >> >> > > an appropriate choice for cases where the nodes share an > >> appropriate > >> >> > > security association that enables the use of AH. > >> >> > > >> >> > How about recommending IPsec ESP too? > >> >> > >> >> This is an option, but generally authentication is the most important > >> >> component. > >> >> > >> >> > > If the mobile nodes in the ad hoc network have pre-established > >> >> > > security associations, the purposes for which the security > >> >> > > associations are created should include that of authorizing the > >> >> > > processing of DYMO control packets. Given this understanding, the > >> >> > > mobile nodes should be able to use the same authentication > >> mechanisms > >> >> > > based on their IP addresses as they would have used otherwise. > >> >> > > >> >> > And if the mobile nodes in the ad hoc network _don't_ have > >> >> > pre-established security associations? > >> >> > >> >> I believe this falls in the research arena. > >> >> > >> >> > This case is very important for MANEMO types of deployments where > >> NEMO > >> >> > moving networks come and go. > >> >> > > >> >> > Alex > >> >> > > >> >> > > >> ______________________________________________________________________ > >> >> > This email has been scanned by the MessageLabs Email Security > >> System. > >> >> > For more information please visit http://www.messagelabs.com/email > >> >> > > >> ______________________________________________________________________ > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > manet mailing list > >> >> > manet@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/manet > >> >> > > >> >> > >> > > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 12:36:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFY2-0003dW-JE; Mon, 04 Jun 2007 12:36:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvFY2-0003dR-3L for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFY1-0003dJ-Nd for manet@ietf.org; Mon, 04 Jun 2007 12:36:49 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFY0-0008KI-95 for manet@ietf.org; Mon, 04 Jun 2007 12:36:49 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l54Galkg029703 for ; Mon, 4 Jun 2007 17:36:47 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l54Galht016771 for ; Mon, 4 Jun 2007 17:36:47 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 04 Jun 2007 17:36:47 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 17:36:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Comments on DYMO Date: Mon, 4 Jun 2007 17:36:46 +0100 Message-ID: In-Reply-To: <46643704.1060805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on DYMO Thread-Index: AcemwW+2yhvm74f7R8q9mOA0RA52cwABAOiw From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 04 Jun 2007 16:36:47.0184 (UTC) FILETIME=[8B298D00:01C7A6C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > MANEMO configuration and topologies don't necessarily need the HopLimit=20 > field in the UDP payload - it could use the Hop Limit field in the base=20 > header. Also, it does not need to 'relay' or 'proxy' messages, it could=20 > forward them if need were; such that no need to change neither src nor > dst address of base header. This is missing that if we have nodes A - B - C with a hop between them, a DYMO message sent by A is received and processed by B, and then forwarded by B, before reaching C. Just sending it at A with an IP hop limit of 2 will not suffice, the two single hops are necessary. This isn't specific to DYMO, it occurs in OLSR and many other ad hoc routing protocols. I venture to suggest you'll find it necessary too (particularly when you consider the need for bidirectional routes). Note that this is for signalling, data is another matter, there we do use a hop limit of (at least) 2. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 12:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFac-0005KA-52; Mon, 04 Jun 2007 12:39:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvFaa-0005Jx-1s for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFaX-0005JT-VV for manet@ietf.org; Mon, 04 Jun 2007 12:39:25 -0400 Received: from ik-out-1112.google.com ([66.249.90.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFaW-0000Cy-I8 for manet@ietf.org; Mon, 04 Jun 2007 12:39:25 -0400 Received: by ik-out-1112.google.com with SMTP id b32so800876ika for ; Mon, 04 Jun 2007 09:39:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RoaZSylVue/XY1GvAzF1qJ+MniLw10WjGW9lW9eW1B2sHXYAvlnmlMrVEhGzKfweuFemkdXe4KxE/Yrx+zZfYtOQ2072895/XftddjyWgliypfGJEXcrCLkDxT5YgdrzMP3B2Q6WqnSp2bqMg2fX5WRJ8UtJkcDyZRfRy6RWCZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o3rAdsY/m86KoX/r9aSmrE+XIzhkLoxAEKFhYErZxrjIM1irYmz//F5oZ/NmaUUkFXITMOfB7TGnhCHSaYjsIWKakfi30nwzfYFTTdOa5Ro/uv57S58ZOh8S1lJJX9om/Fhz7gt3803b+APG/jaBclkk85qnnnqVi4YgH9H8aGo= Received: by 10.78.186.9 with SMTP id j9mr2098596huf.1180975163568; Mon, 04 Jun 2007 09:39:23 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 4 Jun 2007 09:39:23 -0700 (PDT) Message-ID: <374005f30706040939y7c9beb4cncdfa83ee7c170964@mail.gmail.com> Date: Mon, 4 Jun 2007 22:09:23 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Comments on DYMO In-Reply-To: <46643704.1060805@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46643704.1060805@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 6/4/07, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) wrote: > >>> I will say that if one DYMO router sends a LL multicast, it does not > >>> expect to reach all other DYMO routers in a MANET. > > > >> It should expect to reach all the DYMO routers who subscribed that > > group. > > > > No. Because the LL multicast is only going one hop, and some > > (usually most) other routers are more than one hop away. > > Ok. > > >>> I will say that all DYMO routers in a MANET are expected to be within > >>> one IP hop of another DYMO router. > > > >> Looks not as routing then :-) This is one link, and link-layer > >> 'routing', no? > > > > No. Each DYMO router is within one hop of another (at least one > > other) DYMO router, but not of all other DYMO routers. And then > > you do network layer routing, which is what DYMO is there for. > > Ok. > > So this fits Ian's previous explanation where the DYMO's RREQ/RREP IP > messages are not 'forwarded' but received, processed and other IP > RREQ/RREP constructed and sent. > > In these messages two variables are used: HopLimit and HopCnt. > > The base IPv6 header and the IPv4 header have a field called HopLimit > and TTL respectively. These fields are used extensively to limit > forwarding of packets and keep count of it. > > DYMO calling HopLimit exactly as Hop Limit in IPv6 base header is a > source of confusion to me. They have the same purpose and therefore the same name. Their use is clearly called out differently in the spec as IP TTL/HopLimit and MsgHdr.HopLimit. > DYMO not specifying what to put in the src address of the base header > when constructing new messages is confusing to me. There may need to be some textual changes, related to the "Source's DYMO router" as I explained before. I think the idea is now cleared up though. > I agree with DYMO to use what it sees fit in its messages, especially > when it has been experimented in practice. > > However, that doesn't necessarily make DYMO appropriate for a MANEMO > configuration and topology. > > MANEMO configuration and topologies don't necessarily need the HopLimit > field in the UDP payload - it could use the Hop Limit field in the base > header. Also, it does not need to 'relay' or 'proxy' messages, it could > forward them if need were; such that no need to change neither src nor > dst address of base header. > > MANEMO is the main reason why I post remarks on DYMO. I would invite > MANET readers to read MANEMO documents and remark on those too. > Alexandru, I am very glad to see your comments about DYMO and enjoy making the DYMO spec better. I also hope that we can also make progress in the MANEMO area, as I think this will require a lot of knowledge from both groups. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 12:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFlS-0007eD-J8; Mon, 04 Jun 2007 12:50:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvFlQ-0007e8-Pn for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFlP-0007du-VG for manet@ietf.org; Mon, 04 Jun 2007 12:50:40 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvFlO-0001JG-MH for manet@ietf.org; Mon, 04 Jun 2007 12:50:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1180975838!21645000!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27404 invoked from network); 4 Jun 2007 16:50:38 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 4 Jun 2007 16:50:38 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54Gobws016394; Mon, 4 Jun 2007 09:50:37 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l54GobmJ002625; Mon, 4 Jun 2007 11:50:37 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l54GoZKN002604; Mon, 4 Jun 2007 11:50:36 -0500 (CDT) Message-ID: <466442DB.5050506@gmail.com> Date: Mon, 04 Jun 2007 18:50:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Comments on DYMO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: manet , Alexandru Petrescu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> MANEMO configuration and topologies don't necessarily need the >> HopLimit field in the UDP payload - it could use the Hop Limit >> field in the base header. Also, it does not need to 'relay' or >> 'proxy' messages, it could forward them if need were; such that no >> need to change neither src nor dst address of base header. > > This is missing that if we have nodes A - B - C with a hop between > them, a DYMO message sent by A is received and processed by B, and > then forwarded by B, before reaching C. Just sending it at A with an > IP hop limit of 2 will not suffice, the two single hops are > necessary. I think that if the message is really forwarded by B and that if there are two different subnets, one on A-B the other on B-C then it is sufficient to use hoplimit 2 in base header. This assumes that A-B and B-C are different subnets with different prefixes. I think that if you consider that A-B-C are in a situation of hidden terminal problem (A can send to B but not to C, B can send to both A and C) then this hidden terminal problem can be solved by a range extender or other bridging mechanism acting at MAC layer, such that all three A, B and C are in the same subnet. An IP packet sent by A will be bridged by B and IP-received by C. The hop limit in base header should be 1. > This isn't specific to DYMO, it occurs in OLSR and many other ad hoc > routing protocols. I venture to suggest you'll find it necessary too > (particularly when you consider the need for bidirectional routes). > Note that this is for signalling, data is another matter, there we do > use a hop limit of (at least) 2. Christopher, thanks for the clarification. I understand the situation may occur with OLSR and other ad-hoc routing protocols. Could you please suggest what do you think about using a bridge range extender acting at MAC layer, or a repeater repeating all it hears on one interface to the other interface - as a potential solution running on B, thus avoiding the hidden terminal problem? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 13:01:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFw6-0000zy-Py; Mon, 04 Jun 2007 13:01:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvFw5-0000yd-W5 for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 13:01:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFw5-0000yS-MO for manet@ietf.org; Mon, 04 Jun 2007 13:01:41 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFw4-0003CT-7y for manet@ietf.org; Mon, 04 Jun 2007 13:01:41 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l54H1di6008956 for ; Mon, 4 Jun 2007 18:01:39 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l54H1dQk002555 for ; Mon, 4 Jun 2007 18:01:39 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 04 Jun 2007 18:01:39 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 18:01:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Comments on DYMO Date: Mon, 4 Jun 2007 18:01:38 +0100 Message-ID: In-Reply-To: <466442DB.5050506@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on DYMO Thread-Index: AcemyIzOeRJiB0hyQsC3KT51+990NwAAXNKg From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 04 Jun 2007 17:01:39.0209 (UTC) FILETIME=[047A7F90:01C7A6CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >> This is missing that if we have nodes A - B - C with a hop between=20 >> them, a DYMO message sent by A is received and processed by B, and=20 >> then forwarded by B, before reaching C. Just sending it at A with an >> IP hop limit of 2 will not suffice, the two single hops are >> necessary. > I think that if the message is really forwarded by B and that if there > are two different subnets, one on A-B the other on B-C then it is > sufficient to use hoplimit 2 in base header. This assumes that A-B and=20 > B-C are different subnets with different prefixes. I think you aren't picking up on the architecture. A, B and C can be any three nodes in the same MANET, just with A and C outside radio range (or otherwise blocked from communicating). Subnets are a red herring here. > I think that if you consider that A-B-C are in a situation of hidden > terminal problem (A can send to B but not to C, B can send to both A and > C) then this hidden terminal problem can be solved by a range extender > or other bridging mechanism acting at MAC layer, such that all three A, > B and C are in the same subnet. An IP packet sent by A will be bridged > by B and IP-received by C. The hop limit in base header should be 1. That would be a layer 2 routing protocol. You can build layer 2 routing protocols. Many people have - and the jury is still out on which will win in which marketplaces. But here we are building layer 3 routing protocols (though many of the ideas could - and have been - be reused in a layer 2 routing protocol). RFC 2501 is the IETF specific document here, although it's a bit long in the tooth now. It's very easy in a layer 3+ centric organisation to say "make it a layer 2 problem". But you are going to get many of the same problems in both cases. Of course each also has its advantages and disadvantages as well. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 14:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHSB-0001cm-Pz; Mon, 04 Jun 2007 14:38:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvHSA-0001cf-Gp for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHSA-0001cX-7G for manet@ietf.org; Mon, 04 Jun 2007 14:38:54 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvHS9-0000ED-QU for manet@ietf.org; Mon, 04 Jun 2007 14:38:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1180982332!14507825!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 24007 invoked from network); 4 Jun 2007 18:38:52 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-128.messagelabs.com with SMTP; 4 Jun 2007 18:38:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l54IcqkW003791; Mon, 4 Jun 2007 11:38:52 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l54IcpDP023936; Mon, 4 Jun 2007 13:38:51 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-190.corp.mot.com [10.169.4.190]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l54Ickp3023890; Mon, 4 Jun 2007 13:38:49 -0500 (CDT) Message-ID: <46645C35.7030500@gmail.com> Date: Mon, 04 Jun 2007 20:38:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Comments on DYMO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-0, 04/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: manet , Alexandru Petrescu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >>> This is missing that if we have nodes A - B - C with a hop >>> between them, a DYMO message sent by A is received and processed >>> by B, and then forwarded by B, before reaching C. Just sending it >>> at A with an IP hop limit of 2 will not suffice, the two single >>> hops are necessary. > >> I think that if the message is really forwarded by B and that if >> there are two different subnets, one on A-B the other on B-C then >> it is sufficient to use hoplimit 2 in base header. This assumes >> that A-B and B-C are different subnets with different prefixes. > > I think you aren't picking up on the architecture. A, B and C can be > any three nodes in the same MANET, just with A and C outside radio > range (or otherwise blocked from communicating). Subnets are a red > herring here. I agree that A-B and B-C two different subnets is one possibility, and you pointing this is not the right architecture makes me think you think of the second case below. >> I think that if you consider that A-B-C are in a situation of >> hidden terminal problem (A can send to B but not to C, B can send >> to both A and C) then this hidden terminal problem can be solved by >> a range extender or other bridging mechanism acting at MAC layer, >> such that all three A, B and C are in the same subnet. An IP >> packet sent by A will be bridged by B and IP-received by C. The >> hop limit in base header should be 1. > > That would be a layer 2 routing protocol. You can build layer 2 > routing protocols. I think I'm not proposing routing protocol, but yes, at layer 2. I'm writing about a dumb repeater, a range extender, making it just like an Ethernet repeater: what it hears on left puts on right and vice-versa. In the hidden terminal problem A-B-C, if C can't hear A it's because the range is not enough, the physical distance is too long between A and C, or the transmission power is limited by gov't/federal restrictions on emit power in unlicensed spectrum. The same problem appears with wired Ethernet when the cable is too long, except it's not gov't regulatory; and the solution is a repeater. > Many people have - and the jury is still out on which will win in > which marketplaces. I agree with this reflexion, but I didn't mean the routing part in layer-2 protocol. I meant repeating and bridging. I think repeaters and bridges have their large shares in the wired markeplaces and have been built at least by communities in search of wifi Internet access over large areas. > But here we are building layer 3 routing protocols (though many of > the ideas could - and have been - be reused in a layer 2 routing > protocol). RFC 2501 is the IETF specific document here, although it's > a bit long in the tooth now. > > It's very easy in a layer 3+ centric organisation to say "make it a > layer 2 problem". But you are going to get many of the same problems > in both cases. Of course each also has its advantages and > disadvantages as well. I agree it were incorrectly easy to say just make it another layer's problem - only if it didn't have a solution :-) But the hidden terminal problem does have solutions, in WiFi deployments it's called range extenders and is deployed by some, as a repeater. I don't understand what you mean by one is going to get many of the same problems in both cases. If layer-2 does the bridging then the hidden terminal problem is solved I don't see where else can same problem arise. Finally, still as my MANET perspective: if MANET protocols try to solve this asymmetricity problem (we seem to agree it's the hidden terminal problem) with a layer-3 routing protocol then I'm not against it. Just to say that does not mean that all WLAN deployments ressembling a MANET (routers that move around) should solve the problems in the same way as MANET protocols do. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 04 16:00:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIiv-0002MB-Ap; Mon, 04 Jun 2007 16:00:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvIiu-0002Ls-0A for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIit-0002Lk-Mb for manet@ietf.org; Mon, 04 Jun 2007 16:00:15 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIip-0005aa-P3 for manet@ietf.org; Mon, 04 Jun 2007 16:00:15 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1180465wxc for ; Mon, 04 Jun 2007 13:00:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DDPGBWo+cHGxXcVBX4ttk2qWBZ5G0qLWPWmLAGIGM8cznb2yyCX8UNpxf2GQaFMs7t3QRbRXhsTwxz1E306H1HM3W0Rn37FV7e62i8D4S2kcWe8qBgpC3PSyQGOgc+3UJHfWzz40KkQkBndx/R9MUYWZYsycnoa0g20YAnZ3AJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tAwkx+Qvq3C1LPhLQBEG2Izw52wZ0eebcC3KiEDeIhsI9v4qtE7rTmbkMwtMVWVTgLWfpoHi6eCaihineEpIbItYMZVmQ/lTnxCa+HyWkRWWjUt3hS393ALSwMNpc3pALcOvknCkL/xWIPEe2ITctpzUnNES0xEswFEWHGN/Uo0= Received: by 10.90.75.10 with SMTP id x10mr4215674aga.1180987208889; Mon, 04 Jun 2007 13:00:08 -0700 (PDT) Received: by 10.90.102.9 with HTTP; Mon, 4 Jun 2007 13:00:08 -0700 (PDT) Message-ID: Date: Mon, 4 Jun 2007 22:00:08 +0200 From: "Abdelouahid Derhab" To: harry2511 Subject: Re: [manet] GPSR source code In-Reply-To: <10953160.post@talk.nabble.com> MIME-Version: 1.0 References: <10953160.post@talk.nabble.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1947070033==" Errors-To: manet-bounces@ietf.org --===============1947070033== Content-Type: multipart/alternative; boundary="----=_Part_4109_28036485.1180987208840" ------=_Part_4109_28036485.1180987208840 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I think you confuse between GPSR that stands for "Greedy Perimeter Stateles= s Routing", which is a routing protocol and GPRS (General Packet Radio Service). What I am looking for is GPSR and not GPRS. Regards, Abdelouahid On 6/4/07, harry2511 wrote: > > > hi > i am also looking for umts code or model for opnet or for glomosim. if u > find this plesae forward this too me too. i need this urgently for my > project. > thanks > > Abdelouahid Derhab wrote: > > > > Hi, > > > > I am looking for the source code for GPSR routing protocol implemented > > under glomosim. Is it possible to get it? > > > > Thanks in advance. > > > > Best regards. > > Abdelouahid. > > > > -- > > Name: Abdelouahid Derhab > > > > Affiliation: Basic software laboratory, CERIST. > > > > Address: Rue des 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg= =E9rie > > > > Tel +213 21 91 62 05/08 > > > > Fax +213 21 91 21 26 > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > -- > View this message in context: > http://www.nabble.com/GPSR-source-code-tf3863778.html#a10953160 > Sent from the IETF - manet mailing list archive at Nabble.com. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --=20 Name: Abdelouahid Derhab Affiliation: Basic software laboratory, CERIST. Address: Rue des 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg=E9ri= e Tel +213 21 91 62 05/08 Fax +213 21 91 21 26 ------=_Part_4109_28036485.1180987208840 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
I think you confuse between GPSR that stands for "Greedy Perimete= r Stateless Routing", which is a routing protocol and GPRS (General Packet Radio Service). What I am looking for is = GPSR and not GPRS.
 
Regards,
Abdelouahid

 
On 6/4/07, h= arry2511 <harry2511@redi= ffmail.com> wrote:

hi
i am also looking for = umts code or model for opnet or for glomosim. if u
find this plesae forw= ard this too me too. i need this urgently for my
project.
thanks

Abdelouahid Derhab wrote:
>
> Hi,=
>
> I am looking for the source code for GPSR  routi= ng protocol implemented
> under glomosim. Is it possible to get it?>
> Thanks in advance.
>
> Best regards.
> Abdelouah= id.
>
> --
> Name: Abdelouahid Derhab
>
> Aff= iliation: Basic software laboratory, CERIST.
>
> Address: Rue d= es 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg=E9rie
>
> Tel +213 21 91 62 05/08
>
> Fax +213 21 91 21 = 26
>
> _______________________________________________
> = manet mailing list
> manet@ietf.org
> https= ://www1.ietf.org/mailman/listinfo/manet
>
>

--
Vi= ew this message in context: http://www.nabble.com/GPSR-source-code-tf3863778.html#a10953160
Sent= from the IETF - manet mailing list archive at Nabble.com.



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



--
Name: Abdelouahid Derhab

Affiliation: Basic software labo= ratory, CERIST.

Address: Rue des 3 fr=E8res A=EFssou Ben Aknoun BP 1= 43 Alger 16030 Alg=E9rie

Tel +213 21 91 62 05/08

Fax +213 21 = 91 21 26=20 ------=_Part_4109_28036485.1180987208840-- --===============1947070033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1947070033==-- From manet-bounces@ietf.org Mon Jun 04 16:43:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJP7-0006Ef-39; Mon, 04 Jun 2007 16:43:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvJP5-0006Dw-3w for manet-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:43:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJP4-0006Dh-5Y for manet@ietf.org; Mon, 04 Jun 2007 16:43:50 -0400 Received: from hotmail2.netcop.nl ([194.109.204.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJP3-0004KD-Jl for manet@ietf.org; Mon, 04 Jun 2007 16:43:50 -0400 Received: by hotmail2.netcop.nl (Postfix, from userid 500) id 1FD5F78001A; Mon, 4 Jun 2007 22:43:48 +0200 (CEST) Received: from Teco (unknown [83.68.28.151]) by hotmail2.netcop.nl (Postfix) with ESMTP id A69FF780018; Mon, 4 Jun 2007 22:43:45 +0200 (CEST) From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Dearlove, Christopher \(UK\)'" Subject: RE: [manet] Comments on DYMO Date: Mon, 4 Jun 2007 22:44:41 +0200 Message-ID: <000601c7a6e9$2e1c0ed0$05000100@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46645C35.7030500@gmail.com> Thread-Index: Acem19Sy9mOHtgNWR2CLMIzZ6pAa/gAEG9Mg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailscan: CLEAN X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Please do not overload the term "hidden terminal". I think it is misused. The term is borrowed from "hidden terminal problem" and this has to do with CSMA/CA where carrier sensing has some problems. RTS - CTS partly solves this problem, see MACA (D. Allen) and MACAW (V. Bharghavan) for details. Teco > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: maandag 4 juni 2007 20:39 > To: Dearlove, Christopher (UK) > Cc: manet; Alexandru Petrescu > Subject: Re: [manet] Comments on DYMO > > Dearlove, Christopher (UK) wrote: > >>> This is missing that if we have nodes A - B - C with a hop > >>> between them, a DYMO message sent by A is received and processed > >>> by B, and then forwarded by B, before reaching C. Just sending it > >>> at A with an IP hop limit of 2 will not suffice, the two single > >>> hops are necessary. > > > >> I think that if the message is really forwarded by B and that if > >> there are two different subnets, one on A-B the other on B-C then > >> it is sufficient to use hoplimit 2 in base header. This assumes > >> that A-B and B-C are different subnets with different prefixes. > > > > I think you aren't picking up on the architecture. A, B and C can be > > any three nodes in the same MANET, just with A and C outside radio > > range (or otherwise blocked from communicating). Subnets are a red > > herring here. > > I agree that A-B and B-C two different subnets is one possibility, and > you pointing this is not the right architecture makes me think you think > of the second case below. > > >> I think that if you consider that A-B-C are in a situation of > >> hidden terminal problem (A can send to B but not to C, B can send > >> to both A and C) then this hidden terminal problem can be solved by > >> a range extender or other bridging mechanism acting at MAC layer, > >> such that all three A, B and C are in the same subnet. An IP > >> packet sent by A will be bridged by B and IP-received by C. The > >> hop limit in base header should be 1. > > > > That would be a layer 2 routing protocol. You can build layer 2 > > routing protocols. > > I think I'm not proposing routing protocol, but yes, at layer 2. I'm > writing about a dumb repeater, a range extender, making it just like an > Ethernet repeater: what it hears on left puts on right and vice-versa. > > In the hidden terminal problem A-B-C, if C can't hear A it's because the > range is not enough, the physical distance is too long between A and C, > or the transmission power is limited by gov't/federal restrictions on > emit power in unlicensed spectrum. The same problem appears with wired > Ethernet when the cable is too long, except it's not gov't regulatory; > and the solution is a repeater. > > > Many people have - and the jury is still out on which will win in > > which marketplaces. > > I agree with this reflexion, but I didn't mean the routing part in > layer-2 protocol. I meant repeating and bridging. > > I think repeaters and bridges have their large shares in the wired > markeplaces and have been built at least by communities in search of > wifi Internet access over large areas. > > > But here we are building layer 3 routing protocols (though many of > > the ideas could - and have been - be reused in a layer 2 routing > > protocol). RFC 2501 is the IETF specific document here, although it's > > a bit long in the tooth now. > > > > It's very easy in a layer 3+ centric organisation to say "make it a > > layer 2 problem". But you are going to get many of the same problems > > in both cases. Of course each also has its advantages and > > disadvantages as well. > > I agree it were incorrectly easy to say just make it another layer's > problem - only if it didn't have a solution :-) > > But the hidden terminal problem does have solutions, in WiFi deployments > it's called range extenders and is deployed by some, as a repeater. > > I don't understand what you mean by one is going to get many of the same > problems in both cases. If layer-2 does the bridging then the hidden > terminal problem is solved I don't see where else can same problem arise. > > Finally, still as my MANET perspective: if MANET protocols try to solve > this asymmetricity problem (we seem to agree it's the hidden terminal > problem) with a layer-3 routing protocol then I'm not against it. Just > to say that does not mean that all WLAN deployments ressembling a MANET > (routers that move around) should solve the problems in the same way as > MANET protocols do. > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 05 01:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRMM-0005b6-IG; Tue, 05 Jun 2007 01:13:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvRMH-0005YA-Ky for manet-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 01:13:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRMF-0005UK-A2 for manet@ietf.org; Tue, 05 Jun 2007 01:13:27 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvRMD-0003ri-BE for manet@ietf.org; Tue, 05 Jun 2007 01:13:27 -0400 Received: from ex1.ad.dcs.gla.ac.uk ([130.209.249.157]:47400) by mr1.dcs.gla.ac.uk with esmtp (Exim 4.42) id 1HvRMB-0002ep-V7; Tue, 05 Jun 2007 06:13:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Jun 2007 06:11:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFPs- 2nd ACM Workshop on Performance Monitoring, Measurement, and Evaluation of Heterogeneous Wireless and Wired Networks Thread-Index: AceAS1AqyeQkr4KjQLW4M7GNE7LiDwAtP6BfAFdaawwJNHyXNQAAFfOW References: <4623AEF4.9070604@dsi.uclm.es> From: "Mohamed Ould-Khaoua" To: , X-Spam-Score: 0.5 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: blanca@dsi.uclm.es, rwerner@site.uottawa.ca Subject: [manet] CFPs- 2nd ACM Workshop on Performance Monitoring, Measurement, and Evaluation of Heterogeneous Wireless and Wired Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1717582440==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1717582440== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A730.3D671C70" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A730.3D671C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Apologies if you receive multiple copies of this CFPs] -------------------------------------------------------------------------= ----------------- CALL FOR PAPERS =20 2nd ACM International Workshop on Performance Monitoring, Measurement, and Evaluation of Heterogeneous Wireless and Wired Networks- PM2HW2N'07 =20 http://www.i3a.uclm.es/pm2hw2n07/ To be held in conjunction with=20 10th ACM/IEEE International Symposium on Modeling, Analysis and = Simulation=20 of Wireless and Mobile Systems - MSWiM'07 http://www.cs.unibo.it/projects/mswim2007/ October 22 - 26, 2007 Chania, Crete Island, Greece SCOPE: Wireless networks, including ad hoc, sensor, along with ubiquitous, have witnessed over the past few years their fastest growth period and have become increasingly complex. Nonetheless, their performance evaluation and analysis have been conducted mostly through software simulations (e.g. using ns-2 or OPNET tools). Very recently, some research efforts have been directed towards measuring real-world commercial and experimental networks; constructing models based on real-world data and using prototypes to more realistically and comprehensively evaluate the suggested solutions and more specifically validate the assumptions and the conclusions reached via the simulation approach. The monitoring, measurements, and evaluation of heterogeneous wired and wireless mobile networks poses a new set of unique challenges due to the unique inherent properties of these systems and due to the characteristics of the wireless transmission medium. The aim of this workshop, whose 1st edition was held in 2006 in Torremolinos (Spain), is to bring together scientists, engineers, and practitioners to share and exchange their experiences, discuss challenges, and report state-of-the-art and in-progress research on all aspects of performance measurements, monitoring, and evaluation of heterogeneous wired and wireless mobile networks, including, wireless ad hoc, sensor, and ubiquitous networks. A detailed list on the workshop topics can be found at the PM2HW2N'07;s site: http://www.i3a.uclm.es/pm2hw2n07/ ORGANIZATION: =20 Program Chair Blanca CAMINERO, University of Castilla-La Mancha, Albacete, Spain Contact: blanca at dsi.uclm.es Program Vice-Chair Richard PAZZI, University of Ottawa, Ottawa, Canada Contact: rwerner at site.uottawa.ca TECHNICAL PROGRAM COMMITTEE (in progress)=20 N. Abu-Ghazaleh, SUNY-Binghamton (USA) K. Al-Begain, University of Glamorgan (UK) I. Awan, University of Bradford (UK) A. Bermudez, University of Castilla-La Mancha (Spain) R. Beyah, GSU (USA) J.C. Cano, Technical University of Valencia (Spain) C. Carrion, University of Castilla-La Mancha (Spain) M. Colajanni, University of Modena (Italy) P. Cuenca, University of Castilla-La Mancha (Spain) G. Dodero, Free University of Bozen-Bolzano (Italy) E. Fleury, INSA de Lyon (France) X. Jin,University of Bradford (UK) E. Karatza, Aristotle University of Thessaloniki (Greece) G. Min, University of Bradford (UK) M. Naimi, University of Cergy-Pontoise (France) S. Nikoletseas, Computer Technology Institute (Greece) T. Olivares, University of Castilla-La Mancha (Spain) L. Orozco-Barbosa, University of Castilla-La Mancha (Spain) A. Passarella, CNR-IIT Pisa (Italy) M. Perez-Malumbres, Miguel Hernandez University (Spain) F. Quiles, University of Castilla-La Mancha (Spain) P. Ruiz, University of Murcia (Spain) J. A. Sanchez-Laguna, University of Murcia (Spain) C. Skianis, NCSR Demokritos (Greece) S. Tilak, San Diego Supercomputing Center/UCSD (USA) A. Zomaya, University of Sydney (Australia) PAPER SUBMISSION: Authors are invited to submit manuscripts reporting original unpublished research and recent developments in the topics related to the workshop. The length of the papers should not exceed 10 single-spaced pages, formatted using the ACM style. LaTex2e and MS Word templates can be found at http://www.acm.org/sigs/pubs/proceed/template.html. All papers will be peer reviewed and the comments will be provided to the authors. Accepted papers will appear in the workshop proceedings, published by ACM. At least one author of accepted papers is expected to attend the workshop to present its contribution. Paper submission must be done electronically through the OpenConf system at http://investigacion.uclm.es/pm2hw2n07/. IMPORTANT DATES: Submission Deadline: 11 June 2007 Author Notification: 1 July 2007 Camera ready: TBA ------_=_NextPart_001_01C7A730.3D671C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First Call for Papers: 2nd ACM = International PM2HW2N 2007 Workshop=0A= =0A= =0A= =0A=
=0A=
[Apologies if you receive multiple = copies of this = CFPs]
----------------------------------------------------------------= --------------------------
CALL FOR = PAPERS           &= nbsp;           &n= bsp;  


2nd ACM International Workshop on = Performance Monitoring, Measurement,
and Evaluation of Heterogeneous = Wireless and Wired Networks- PM2HW2N'07
=0A=
=0A=
=0A=
=0A=
=0A=
 
=0A= =0A=
To be held in conjunction = with 
=0A=
10th ACM/IEEE International Symposium = on  Modeling, Analysis and Simulation =
=0A=
of Wireless and Mobile Systems - = MSWiM'07
=0A=
http://www.cs.unibo.i= t/projects/mswim2007/

October 22 - 26, 2007
Chania, Crete = Island, Greece


SCOPE:
Wireless networks, including ad hoc, = sensor, along with ubiquitous, have
witnessed over the past few years = their fastest growth period and have
become increasingly complex. = Nonetheless, their performance evaluation
and analysis have been = conducted mostly through software simulations
(e.g. using ns-2 or = OPNET tools). Very recently, some research efforts
have been directed = towards measuring real-world commercial and
experimental networks; = constructing models based on real-world data and
using prototypes to = more realistically and comprehensively evaluate the
suggested = solutions and more specifically validate the assumptions and
the = conclusions reached via the simulation approach.

The monitoring, = measurements, and evaluation of heterogeneous wired and
wireless = mobile networks poses a new set of unique challenges due to = the
unique inherent properties of these systems and due to = the
characteristics of the wireless transmission medium.

The = aim of this workshop, whose 1st edition was held in 2006 = in
Torremolinos (Spain), is to bring together scientists, engineers, = and
practitioners to share and exchange their experiences, = discuss
challenges, and report state-of-the-art and in-progress = research on all
aspects of performance measurements, monitoring, and = evaluation of
heterogeneous wired and wireless mobile networks, = including, wireless ad
hoc, sensor, and ubiquitous networks.

A = detailed list on the workshop topics can be found at the = PM2HW2N'07;s
=0A= =0A=
ORGANIZATION:
=0A=
 
=0A=
Program Chair
Blanca CAMINERO, = University of Castilla-La Mancha, Albacete, Spain
Contact: blanca at = dsi.uclm.es

Program Vice-Chair
Richard PAZZI, University of = Ottawa, Ottawa, Canada
Contact: rwerner at = site.uottawa.ca


TECHNICAL PROGRAM COMMITTEE
=0A=
(in progress) 

N. = Abu-Ghazaleh, SUNY-Binghamton (USA)
K. Al-Begain, University of = Glamorgan (UK)
I. Awan, University of Bradford (UK)
A. Bermudez, = University of Castilla-La Mancha (Spain)
R. Beyah, GSU (USA)
J.C. = Cano, Technical University of Valencia (Spain)
C. Carrion, University = of Castilla-La Mancha (Spain)
M. Colajanni, University of Modena = (Italy)
P. Cuenca, University of Castilla-La Mancha (Spain)
G. = Dodero, Free University of Bozen-Bolzano (Italy)
E. Fleury, INSA de = Lyon (France)
X. Jin,University of Bradford (UK)
E. Karatza, = Aristotle University of Thessaloniki (Greece)
G. Min, University of = Bradford (UK)
M. Naimi, University of Cergy-Pontoise (France)
S. = Nikoletseas, Computer Technology Institute (Greece)
T. Olivares, = University of Castilla-La Mancha (Spain)
L. Orozco-Barbosa, = University of Castilla-La Mancha (Spain)
A. Passarella, CNR-IIT Pisa = (Italy)
M. Perez-Malumbres, Miguel Hernandez University (Spain)
F. = Quiles, University of Castilla-La Mancha (Spain)
P. Ruiz, University = of Murcia (Spain)
J. A. Sanchez-Laguna, University of Murcia = (Spain)
C. Skianis, NCSR Demokritos (Greece)
S. Tilak, San Diego = Supercomputing Center/UCSD (USA)
A. Zomaya, University of Sydney = (Australia)


PAPER SUBMISSION:
Authors are invited to = submit manuscripts reporting original unpublished
research and recent = developments in the topics related to the workshop.
The length of the = papers should not exceed 10 single-spaced pages,
formatted using the = ACM style. LaTex2e and MS Word templates can be
found at http://www.ac= m.org/sigs/pubs/proceed/template.html.

All papers will be = peer reviewed and the comments will be provided to
the authors. = Accepted papers will appear in the workshop proceedings,
published by = ACM. At least one author of accepted papers is expected to
attend the = workshop to present its contribution.

Paper submission must be = done electronically through the OpenConf system
at http://investigacion.ucl= m.es/pm2hw2n07/.

=0A=
IMPORTANT DATES:
Submission = Deadline:   11 June 2007
Author = Notification:    1 July 2007
Camera ready:   = TBA
------_=_NextPart_001_01C7A730.3D671C70-- --===============1717582440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1717582440==-- From manet-bounces@ietf.org Tue Jun 05 04:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUiw-0002XP-7W; Tue, 05 Jun 2007 04:49:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvUiu-0002Ug-2x for manet-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 04:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUis-0002Ts-Sl for manet@ietf.org; Tue, 05 Jun 2007 04:49:02 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUis-0002q9-Fr for manet@ietf.org; Tue, 05 Jun 2007 04:49:02 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l558n1QK021332 for ; Tue, 5 Jun 2007 09:49:01 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l558n1Kq009094 for ; Tue, 5 Jun 2007 09:49:01 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 05 Jun 2007 09:49:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:49:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Comments on DYMO Date: Tue, 5 Jun 2007 09:49:00 +0100 Message-ID: In-Reply-To: <46645C35.7030500@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on DYMO Thread-Index: Acem151JotItXJ/vRc+Z2b3uSxoRMgAcx+oQ From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Jun 2007 08:49:00.0788 (UTC) FILETIME=[5CB32340:01C7A74E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I think I'm not proposing routing protocol, but yes, at layer 2. I'm > writing about a dumb repeater, a range extender, making it just like an > Ethernet repeater: what it hears on left puts on right and vice-versa. That's not going to be sufficient - at least not without reducing to blind flooding. And the whole point of just about all MANET work is that yes, you can blind flood - but not if you want anything remotely efficient. You seem to think you can push the problem from layer 3 to layer 2, and then magic it away at that level. You might consider that if this were the case people might have spotted there were no problems long ago - in fact before I ever heard the phrase "ad hoc network". > In the hidden terminal problem A-B-C As Teco Boot points out, this is not what is usually referred to as the hidden node problem, which is not simply that A can't hear C and you need multi-hop transmission (without which you don't have a MANET) but that refers to a contention problem that occurs because of this case. > if C can't hear A it's because the > range is not enough, the physical distance is too long between A and C, > or the transmission power is limited by gov't/federal restrictions on > emit power in unlicensed spectrum. There are quite a few more possible reasons than that. Here's just one - there's a physical obstacle between A and C. > I agree with this reflexion, but I didn't mean the routing part in > layer-2 protocol. I meant repeating and bridging. Which will not suffice to build an efficient MANET. The people creating routing protocols at layer 2 have to do similar intelligent stuff at layer 2. > I agree it were incorrectly easy to say just make it another layer's > problem - only if it didn't have a solution :-) You really think you've just solved all the problems we've worked on for several years in my case, and more years by many others than me, with a simple layer 2 repeater? > Finally, still as my MANET perspective: if MANET protocols try to solve > this asymmetricity problem (we seem to agree it's the hidden terminal > problem) No. First I wouldn't use the hidden terminal terminology here. And this isn't the asymmetry problem either. The asymmetry problem is if A can hear B, but B can't hear A. That's a detail of the problem though (but one of the reasons why some simpler solutions to the multihop problem are insufficient). > with a layer-3 routing protocol then I'm not against it. Just > to say that does not mean that all WLAN deployments ressembling a MANET > (routers that move around) should solve the problems in the same way as > MANET protocols do. If you don't want blind flooding (and we don't) then you've got to do something intelligent at layer 2, or layer 3, or both, or combining the two, or something similar. Those are all MANET protocols. They may or may not be the IETF MANET WG protocols (though using them, their predecessors, or their ideas, is common). The last time I looked (quite a few years ago) I stopped counting at about 50 different MANET routing protocols. I'm sure there are at least that many more again. Of course they reuse ideas. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 05 06:18:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvW7L-0000Yv-Kw; Tue, 05 Jun 2007 06:18:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvW7K-0000Yq-CP for manet-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 06:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvW7K-0000Yi-2r for manet@ietf.org; Tue, 05 Jun 2007 06:18:22 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvW7J-0003og-MY for manet@ietf.org; Tue, 05 Jun 2007 06:18:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1181038700!6479370!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 20939 invoked from network); 5 Jun 2007 10:18:20 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-128.messagelabs.com with SMTP; 5 Jun 2007 10:18:20 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l55AIK6U023287; Tue, 5 Jun 2007 03:18:20 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l55AIJ1k028987; Tue, 5 Jun 2007 05:18:19 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l55AIHhx028906; Tue, 5 Jun 2007 05:18:18 -0500 (CDT) Message-ID: <46653865.6070301@gmail.com> Date: Tue, 05 Jun 2007 12:18:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Comments on DYMO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-0, 04/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Christopher, thanks for the message. Just wanted to point out that although I disagree with you on many points below, it is far from my intentions to neglect prior work on MANET, MAC, layer-2 and 3 routing; or to do any inefficient blind flooding. It's just that there are certainly MANET-like contexts where many of the problems revealed by the most special MANET testbeds are not necessarily quantifiable and addressable problems for some deployments. I think of an IETF meeting packed with people doing Internet over WiFi, and I think about what are the problems that were raised... or I think about vehicles in a large parking doing the same. Alex Dearlove, Christopher (UK) wrote: >> I think I'm not proposing routing protocol, but yes, at layer 2. >> I'm writing about a dumb repeater, a range extender, making it just >> like > an >> Ethernet repeater: what it hears on left puts on right and >> vice-versa. > > That's not going to be sufficient - at least not without reducing to > blind flooding. And the whole point of just about all MANET work is > that yes, you can blind flood - but not if you want anything > remotely efficient. > > You seem to think you can push the problem from layer 3 to layer 2, > and then magic it away at that level. You might consider that if this > were the case people might have spotted there were no problems long > ago - in fact before I ever heard the phrase "ad hoc network". > >> In the hidden terminal problem A-B-C > > As Teco Boot points out, this is not what is usually referred to as > the hidden node problem, which is not simply that A can't hear C and > you need multi-hop transmission (without which you don't have a > MANET) but that refers to a contention problem that occurs because of > this case. > >> if C can't hear A it's because the range is not enough, the >> physical distance is too long between A and > C, >> or the transmission power is limited by gov't/federal restrictions >> on emit power in unlicensed spectrum. > > There are quite a few more possible reasons than that. Here's just > one - there's a physical obstacle between A and C. > >> I agree with this reflexion, but I didn't mean the routing part in >> layer-2 protocol. I meant repeating and bridging. > > Which will not suffice to build an efficient MANET. The people > creating routing protocols at layer 2 have to do similar intelligent > stuff at layer 2. > >> I agree it were incorrectly easy to say just make it another >> layer's problem - only if it didn't have a solution :-) > > You really think you've just solved all the problems we've worked on > for several years in my case, and more years by many others than me, > with a simple layer 2 repeater? > >> Finally, still as my MANET perspective: if MANET protocols try to > solve >> this asymmetricity problem (we seem to agree it's the hidden >> terminal problem) > > No. First I wouldn't use the hidden terminal terminology here. And > this isn't the asymmetry problem either. The asymmetry problem is if > A can hear B, but B can't hear A. That's a detail of the problem > though (but one of the reasons why some simpler solutions to the > multihop problem are insufficient). > >> with a layer-3 routing protocol then I'm not against it. Just to >> say that does not mean that all WLAN deployments ressembling a > MANET >> (routers that move around) should solve the problems in the same >> way > as >> MANET protocols do. > > If you don't want blind flooding (and we don't) then you've got to do > something intelligent at layer 2, or layer 3, or both, or combining > the two, or something similar. Those are all MANET protocols. They > may or may not be the IETF MANET WG protocols (though using them, > their predecessors, or their ideas, is common). The last time I > looked (quite a few years ago) I stopped counting at about 50 > different MANET routing protocols. I'm sure there are at least that > many more again. Of course they reuse ideas. > > ******************************************************************** > 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 has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 05 08:05:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXmT-0002Us-J0; Tue, 05 Jun 2007 08:04:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvXmR-0002Un-MT for manet-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 08:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXmR-0002UW-7f for manet@ietf.org; Tue, 05 Jun 2007 08:04:55 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvXmL-0000Bh-MY for manet@ietf.org; Tue, 05 Jun 2007 08:04:55 -0400 Received: from smtps.inrialpes.fr (smtps.inrialpes.fr [194.199.18.58]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id l55C4dbA006443; Tue, 5 Jun 2007 14:04:39 +0200 (MEST) Received: from [134.214.146.222] (bigbrother.citi.insa-lyon.fr [134.214.146.222]) (authenticated bits=0) by smtps.inrialpes.fr (8.13.7/8.13.4) with ESMTP id l55C4d1g006743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 14:04:40 +0200 Message-ID: <46655152.1050305@inria.fr> Date: Tue, 05 Jun 2007 14:04:34 +0200 From: "Prof. Eric Fleury CITI/ARES" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: arp@cines.fr, asr.rescom@cines.fr, manet@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 05 Jun 2007 14:04:39 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0, requis 5) X-mx-serv-inrialpes-fr-MailScanner-From: eric.fleury@inria.fr X-Spam-Status: No Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx-serv.inrialpes.fr id l55C4dbA006443 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Subject: [manet] CFP_3rd International Conference on Mobile Ad-hoc and Sensor Networks (MSN'07) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *3rd International Conference on * *Mobile Ad-hoc and Sensor Networks (MSN'07)* * 12 =96 14 December 2007, Beijing, China* *http://conference.bjtu.edu.cn/msn07 * *General Co-Chairs * Jiannong Cao, Hong Kong Polytechnic Univ., HK Dave Johnson, Rice Univ., USA *Program Co-Chairs * Hongke Zhang, Beijing Jiaotong Univ., China Stephan Olariu, Old Dominion Univ., USA *Program Vice Chairs* Eric Fleury, CITI/ARES, France Vojislav B. Misic, Univ. Manitoba, Canada Pedro M. Ruiz, Univ. of Murcia, Spain *Publicity Co-Chairs* Jong Hyuk, R&D Institute, Seoul, Korea Paolo Bellavista, University of Bologna, Italy Deyun Gao, Beijing Jiaotong Univ., China *Publication Chair * Zhang Ling, Tsinghua Univ., China *Local Organization Co-Chairs * Deyun Gao, Beijing Jiaotong Univ., China Yajuan Qin, Beijing Jiaotong Univ., China *Awards Co-chairs* Sagar Naik, Univ of Waterloo, Canada Christian Lavault, University Paris XIII, France Cristina Pinotti, Unvi Perugia, Italy** *Program Committee Members* *Please see **MSN'07** Website for the list of program committee members*= * * *Steering Committee* Xiaohua Jia (Chair), City Univ. of Hong Kong, HK Jiannong Cao (Co-Chair), Hong Kong Polytechnic Univ., HK Sajal K. Das, Univ. of Texas at Arlington, USA Ivan Stojmenovic, Univ. of Ottawa , Canada Jie Wu, Florida Atalantic Univ., USA *Webmaster * Hongwei Huo, Beijing Jiaotong Univ., China *CONFERENCE TOPICS * Following the success of the past two conferences, MSN'05 in Wuhan, China and MSN'06 in Hong Kong, MSN'07 provides a forum for researchers and practitioners to exchange research results and share development experiences. Topics of interest include, but are not limited to, the following areas in mobile ad hoc and sensor networks: ? Network architecture and protocols ? Software platforms and development tools ? Self-organization and synchronization ? Routing and data dissemination ? Failure resilience and fault isolation ? Energy Management ? Data, information, and signal processing ? Security and privacy ? Network planning, provisioning, and deployment ? Developments and applications ? Integration with other system *PAPER SUBMISSION * MSN invites authors to submit original and unpublished work. Submissions should include an abstract, key words, the e-mail address of the corresponding author, and must not exceed 15 pages, including tables and figures, with PDF, PostScript, or MSWord format. Electronic submission through the submission website is strongly encouraged. Submission of a pa= per should be regarded as an undertaking that, should the paper be accepted, = at least one of the authors will register and attend the conference to prese= nt the work. ** *PROCEEDINGS * The conference proceedings will be published as Springer-LNCS series (pending) and distributed at the conference. One Best Paper and one Best Student Paper will be selected for awards. Each winner will be presented = at the conference with a certificate and US$100. *IMPORTANT DATES * *Submission deadline: 30 June, 2007** * * Notification of acceptance: 10 August 2007*** * Final Manuscript due: 1 September 2007* *Organized and supported by Beijing Jiaotong University * ------------------------------------------------------------------------ _______________________________________________ Tccc mailing list Tccc@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/tccc --=20 Eric FLEURY PROF. AT INSA of LYON Co-HEAD OF CITI LAB & Co-Leader of ARES INRIA PROJECT TEL: +33 472 436 421/+33 672 162 974 FAX: +33 472 436 227 WEB: http://perso.citi.insa-lyon.fr/efleury/=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 05 23:58:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvmfX-0005jf-3P; Tue, 05 Jun 2007 23:58:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvmfV-0005jU-Nz for manet-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 23:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvmfV-0005jM-Ea for manet@ietf.org; Tue, 05 Jun 2007 23:58:45 -0400 Received: from m13-2.163.com ([220.181.13.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvmfT-0003Oj-FM for manet@ietf.org; Tue, 05 Jun 2007 23:58:45 -0400 Received: from 220.181.12.225 ( 220.181.12.225 [220.181.12.225] ) by webmail-app2 (Coremail) ; Wed, 6 Jun 2007 11:58:41 +0800 (CST) MIME-Version: 1.0 Message-ID: <466630F1.000021.12982@bj163app2.163.com> Date: Wed, 6 Jun 2007 11:58:41 +0800 (CST) From: wsn_2007@163.com To: manet@ietf.org X-Priority: 3 X-Originating-IP: [220.181.12.225] X-Mailer: 163com X-Spam-Score: 4.6 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [manet] about glomosim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0458049173==" Errors-To: manet-bounces@ietf.org --===============0458049173== Content-Type: Multipart/Alternative; boundary="Boundary-=_izoBCHZCIFFTiNICyivpghggmXkq" --Boundary-=_izoBCHZCIFFTiNICyivpghggmXkq Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi,all, I am simulating a WSNs protocol which is data-based using GloMoSim,what i have to midofy about glomosim?Thank you ! --Boundary-=_izoBCHZCIFFTiNICyivpghggmXkq Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit

Hi,all,

   I am simulating a WSNs protocol which is data-based using GloMoSim,what i have to midofy about glomosim?Thank you !



--Boundary-=_izoBCHZCIFFTiNICyivpghggmXkq-- --===============0458049173== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0458049173==-- From manet-bounces@ietf.org Wed Jun 06 04:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvqmA-00056y-1a; Wed, 06 Jun 2007 04:21:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hvqm9-00056t-BP for manet-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 04:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvqm8-00056l-Um for manet@ietf.org; Wed, 06 Jun 2007 04:21:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvqm7-0005wa-Gl for manet@ietf.org; Wed, 06 Jun 2007 04:21:52 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1014763ugc for ; Wed, 06 Jun 2007 01:21:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=k9C0f33JnUBoo0kDj8Gjuc2oQQeAHGADnMiSHMLdh7w98hz5dI3mquN3reiCiRGr+v8UfhhVFkO4UutG4gA9YblWGlOec0jkeINA03FuSpaMMbpi2WKXlfc4Eo1mdk9dG9LirBQ99oTxOdSbYusmVTjVKkqu3q1AzwzsEU5Nxck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mvgWNc+K5ygxiLsX5sgLvrBC2GQv5ZJDkzGHIQ3Lgl8hMjOPOpuAjjRAgaB8Aw5oViRQCU6MyisNSP/1t1XZmeXQX96aQaXnHFpE+ZJ9MDkQK1MBtTSf66eqgMTl3lacXMz4afyEauPaYNl5yQo9EdTEVX3JjlIXRZCdc3Pwmok= Received: by 10.67.10.12 with SMTP id n12mr1110466ugi.1181118110717; Wed, 06 Jun 2007 01:21:50 -0700 (PDT) Received: by 10.67.94.18 with HTTP; Wed, 6 Jun 2007 01:21:50 -0700 (PDT) Message-ID: <87082b010706060121s639b110fs893664a04bf5a8f9@mail.gmail.com> Date: Wed, 6 Jun 2007 10:21:50 +0200 From: "wafa Berrayana" To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [manet] Re: manet Digest, Vol 38, Issue 8 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0419074822==" Errors-To: manet-bounces@ietf.org --===============0419074822== Content-Type: multipart/alternative; boundary="----=_Part_16837_19689222.1181118110681" ------=_Part_16837_19689222.1181118110681 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Please could some one send me an implementation of the QoS AODV. Thank you very much in advance. Have a nice day ------=_Part_16837_19689222.1181118110681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,
Please could some one send me an implementation of the QoS AODV.
Thank you very much in advance.
Have a nice day
------=_Part_16837_19689222.1181118110681-- --===============0419074822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0419074822==-- From manet-bounces@ietf.org Wed Jun 06 04:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvqqb-00069R-22; Wed, 06 Jun 2007 04:26:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HvqqZ-00069J-84 for manet-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 04:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvqqY-000698-UR for manet@ietf.org; Wed, 06 Jun 2007 04:26:26 -0400 Received: from student.murdoch.edu.au ([134.115.4.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvqqX-00072U-5D for manet@ietf.org; Wed, 06 Jun 2007 04:26:26 -0400 Received: from student.murdoch.edu.au (www-data@localhost [127.0.0.1]) by student.murdoch.edu.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l568QLoF003764 for ; Wed, 6 Jun 2007 16:26:21 +0800 Received: (from www-data@localhost) by student.murdoch.edu.au (8.13.4/8.13.4/Submit) id l568QLlS003762 for manet@ietf.org; Wed, 6 Jun 2007 16:26:21 +0800 X-Authentication-Warning: student.murdoch.edu.au: www-data set sender to 30179198@student.murdoch.edu.au using -f Received: from it2054-06.murdoch.edu.au (it2054-06.murdoch.edu.au [134.115.65.137]) by wwwstudent.murdoch.edu.au (Horde MIME library) with HTTP; Wed, 06 Jun 2007 16:26:20 +0800 Message-ID: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> Date: Wed, 06 Jun 2007 16:26:20 +0800 From: David Murray <30179198@student.murdoch.edu.au> To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Spam-Score: 2.2 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [manet] DYMO and other routing protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, I am wondering how DYMO fits in with the other routing protocols. I have read a number of papers that discuss how on-demand routing protocols like DSR/AODV work better in highly mobile environments where movement is fast, CPU and memory are low and batteries are limited. Equally, in situations where movement is very low, and there are no power limitations, protocols like OLSR/TBRPF/STAR perform better. So, I have a mental picture of OLSR/TBRPF being predominantly used in stationary 802.11 mesh devices and AODV/DYMO being used to connect users mobile devices ush as phones and PDAs. Is this correct or are things not quite as simple as this? (I know RFC 2501 discusses MANET applications and characteristics but the discussion is quite general) If this is correct, it seems to me that DYMO and AODV are used in very similar situations (the ad hoc interconnect between users devices). I am aware that DYMO is a simplified version of AODV both in code and network operation. It seems like the major difference is the path accumulation feature in DYMO which allows nodes to append their information to a RREP to give other nodes better knowledge of the topology. It also seems that the hello feature has been removed in DYMO. So, is DYMO likely to be a replacement for AODV or do they have different uses/applications? Thanks for your time Dave _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 06 04:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvr7W-0002eg-Oj; Wed, 06 Jun 2007 04:43:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hvr7U-0002eV-Qm for manet-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 04:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvr7U-0002eN-Gr for manet@ietf.org; Wed, 06 Jun 2007 04:43:56 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvr7T-0003P9-7p for manet@ietf.org; Wed, 06 Jun 2007 04:43:56 -0400 Received: by wr-out-0506.google.com with SMTP id m59so57026wrm for ; Wed, 06 Jun 2007 01:43:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rlCcvePUjZK4EhGK+KLS0wimc/D9dD4A9xFhFi4nv8WhDH2gr65K51bcJjwo+H5W5hBIj1RCcL0bVjfEpfu9TIJhjOkWi1r35TXZ65I9j/8jWq/BzPJEvbzOVJTHlMiJwVg5yhbcnoUiOIYvJwZso+M3nTLaRJU6ckoC06XLDwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HElLXLo0w6JiL5bAN2e/vx/QFvrH1lLpAg3UE5RymdsL0AiMNoJphPiqwNsxkp+Af2jZXwnlC59z8vG/5WPV1gEVpXu9WjGO7y41hKNVNkuCpptNguqd0ADekLWZpJr0nj6cZH+7bsoAGuM0t5RAY8/C87i9J4sr6gzaoRwq+es= Received: by 10.78.81.20 with SMTP id e20mr83039hub.1181119434394; Wed, 06 Jun 2007 01:43:54 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Wed, 6 Jun 2007 01:43:54 -0700 (PDT) Message-ID: <374005f30706060143k484b722by9da68bd6ae847dbb@mail.gmail.com> Date: Wed, 6 Jun 2007 14:13:54 +0530 From: "Ian Chakeres" To: "David Murray" <30179198@student.murdoch.edu.au> Subject: Re: [manet] DYMO and other routing protocols In-Reply-To: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org There is no winner takes all in the contest of routing protocols for MANET. I think each protocol and its supporters can easily make a case where it will beat other protocols. Simply look at conference publications for good examples. That said, we have chosen to standardize DYMO and OLSRv2 - one reactive and one reactive protocol in the MANET WG. For more information regarding when one might deploy one or the other, please see the applicability statements in the drafts. DYMO is a successor to AODV (and other reactive protocols). The specification is chartered to become a proposed standard. AODV is not being actively discussed or standardized in the WG. Ian On 6/6/07, David Murray <30179198@student.murdoch.edu.au> wrote: > Hi, > > I am wondering how DYMO fits in with the other routing protocols. I > have read a number of papers that discuss how on-demand routing > protocols like DSR/AODV work better in highly mobile environments where > movement is fast, CPU and memory are low and batteries are limited. > Equally, in situations where movement is very low, and there are no > power limitations, protocols like OLSR/TBRPF/STAR perform better. > > So, I have a mental picture of OLSR/TBRPF being predominantly used in > stationary 802.11 mesh devices and AODV/DYMO being used to connect > users mobile devices ush as phones and PDAs. Is this correct or are > things not quite as simple as this? (I know RFC 2501 discusses MANET > applications and characteristics but the discussion is quite general) > > If this is correct, it seems to me that DYMO and AODV are used in very > similar situations (the ad hoc interconnect between users devices). I > am aware that DYMO is a simplified version of AODV both in code and > network operation. It seems like the major difference is the path > accumulation feature in DYMO which allows nodes to append their > information to a RREP to give other nodes better knowledge of the > topology. It also seems that the hello feature has been removed in > DYMO. So, is DYMO likely to be a replacement for AODV or do they have > different uses/applications? > > Thanks for your time > > Dave > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 06 14:40:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0Qv-00024T-Fx; Wed, 06 Jun 2007 14:40:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hw0Qt-00024M-UQ for manet-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 14:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0Qt-00024B-Kp for manet@ietf.org; Wed, 06 Jun 2007 14:40:35 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw0Qr-00036L-Tn for manet@ietf.org; Wed, 06 Jun 2007 14:40:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56IeUcP009587; Wed, 6 Jun 2007 21:40:30 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 21:40:29 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 13:40:27 -0500 Received: from [10.162.26.52] ([10.162.26.52]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 13:40:12 -0500 Message-ID: <4666FF85.2040306@nokia.com> Date: Wed, 06 Jun 2007 11:40:05 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres , David Murray <30179198@student.murdoch.edu.au> Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <374005f30706060143k484b722by9da68bd6ae847dbb@mail.gmail.com> In-Reply-To: <374005f30706060143k484b722by9da68bd6ae847dbb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 18:40:12.0505 (UTC) FILETIME=[1DE75C90:01C7A86A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello folks, I am quite hopeful that we can get to a converged routing protocol that will subsume the best aspects of DYMO and OLSR. We have many recent results pointing the way forward, some of which I presented at the last IETF. I am hoping to have a much more complete presentation ready for the next meeting. I think it is clear by now that proactive protocol operation is better when either there is a strong requirement for minimizing latency in an uncongested network, or when the traffic patterns are not very sparse. So, for instance, if most nodes in an ad hoc network have open communications with most other nodes in the same network, the communication pattern is not at all sparse. The tricky point is to find out how dense the traffic pattern needs to be in order to favor proactive operation (or, alternatively, how sparse the traffic has to be in order to favor reactive operation). Furthermore, it is quite likely that some routes should be proactively maintained even if route table entries are generally acquired on demand. The canonical example is that nodes need a route to a gateway [if one exists] (or default router) often enough that the route should always be there. Whether this is done by periodic advertisement or by triggered route repairs is a matter for further study. One could imagine similar requirements might be imposed for important servers in the network (e.g., certificate authority, data sink, ...). I do _not_ think that proactive protocols should automatically be the choice for mesh backbone routers. Certainly not for all mesh clients...! I would really question whether it is needed for all other mesh points anyway. Plus, the whole concept gets quite fuzzy if there are intermittent long-range connections to neighboring meshes (as an example). Regarding the naming of AODV vs. DYMO: this is a long story with as much political as technical content, and for my own part the former was by far the more persuasive factor to persuade me to agree to a new name for the standards-track reactive protocol. Now the downside is that we have exactly the confusion in evidence currently for newly interested parties. Perhaps we should rename DYMO to be AODVv2 :-) Finally, regarding: > I think each protocol and its supporters can easily make a case > where it will beat other protocols. Simply look at conference > publications for good examples. Simply stated: caveat emptor. Stated more verbosely and redundantly using more words and so on... ---> it is very important to fully understand the range of applicability for each research result. These are sometimes not stated very clearly. It is also very helpful, when possible, to understand the motivations of the authors. Regards, Charlie P. ext Ian Chakeres wrote: > There is no winner takes all in the contest of routing protocols for > MANET. I think each protocol and its supporters can easily make a case > where it will beat other protocols. Simply look at conference > publications for good examples. > > That said, we have chosen to standardize DYMO and OLSRv2 - one > reactive and one reactive protocol in the MANET WG. For more > information regarding when one might deploy one or the other, please > see the applicability statements in the drafts. > > DYMO is a successor to AODV (and other reactive protocols). The > specification is chartered to become a proposed standard. AODV is not > being actively discussed or standardized in the WG. > > Ian > > On 6/6/07, David Murray <30179198@student.murdoch.edu.au> wrote: >> Hi, >> >> I am wondering how DYMO fits in with the other routing protocols. I >> have read a number of papers that discuss how on-demand routing >> protocols like DSR/AODV work better in highly mobile environments where >> movement is fast, CPU and memory are low and batteries are limited. >> Equally, in situations where movement is very low, and there are no >> power limitations, protocols like OLSR/TBRPF/STAR perform better. >> >> So, I have a mental picture of OLSR/TBRPF being predominantly used in >> stationary 802.11 mesh devices and AODV/DYMO being used to connect >> users mobile devices ush as phones and PDAs. Is this correct or are >> things not quite as simple as this? (I know RFC 2501 discusses MANET >> applications and characteristics but the discussion is quite general) >> >> If this is correct, it seems to me that DYMO and AODV are used in very >> similar situations (the ad hoc interconnect between users devices). I >> am aware that DYMO is a simplified version of AODV both in code and >> network operation. It seems like the major difference is the path >> accumulation feature in DYMO which allows nodes to append their >> information to a RREP to give other nodes better knowledge of the >> topology. It also seems that the hello feature has been removed in >> DYMO. So, is DYMO likely to be a replacement for AODV or do they have >> different uses/applications? >> >> Thanks for your time >> >> Dave >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 06:36:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwbpk-0008Rt-A4; Fri, 08 Jun 2007 06:36:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hwbpi-0008Rn-JV for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 06:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwbpi-0008Rf-9s for manet@ietf.org; Fri, 08 Jun 2007 06:36:42 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwbph-0003pm-Oo for manet@ietf.org; Fri, 08 Jun 2007 06:36:42 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1181299000!12464301!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30722 invoked from network); 8 Jun 2007 10:36:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 8 Jun 2007 10:36:40 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l58Aaeo2028973; Fri, 8 Jun 2007 03:36:40 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l58AadGl009211; Fri, 8 Jun 2007 05:36:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l58AabQJ009119; Fri, 8 Jun 2007 05:36:38 -0500 (CDT) Message-ID: <4669312D.3000608@gmail.com> Date: Fri, 08 Jun 2007 12:36:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <374005f30706060143k484b722by9da68bd6ae847dbb@mail.gmail.com> <4666FF85.2040306@nokia.com> In-Reply-To: <4666FF85.2040306@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-0, 07/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charles E. Perkins wrote: > > Hello folks, > > I am quite hopeful that we can get to a converged routing protocol > that will subsume the best aspects of DYMO and OLSR. I'm in the process of reading OLSRv2 spec for seeing it fitting MANEMO topologies. As an external, I must say that I would very much favor only one MANET routing protocol and not two. It simply takes too much effort to just read two documents (30+70 pages), not even mention the time it takes to implement both protocols. If possible, the length of a common protocol document should be upper bounded, something like half the sum of parts. Covergence is the only option now, IMHO, after all this time. Alex > We have many recent results pointing the way forward, some of which I > presented at the last IETF. I am hoping to have a much more > complete presentation ready for the next meeting. > > I think it is clear by now that proactive protocol operation is > better when either there is a strong requirement for minimizing > latency in an uncongested network, or when the traffic patterns are > not very sparse. So, for instance, if most nodes in an ad hoc > network have open communications with most other nodes in the same > network, the communication pattern is not at all sparse. The tricky > point is to find out how dense the traffic pattern needs to be in > order to favor proactive operation (or, alternatively, how sparse the > traffic has to be in order to favor reactive operation). > > Furthermore, it is quite likely that some routes should be > proactively maintained even if route table entries are generally > acquired on demand. The canonical example is that nodes need a route > to a gateway [if one exists] (or default router) often enough that > the route should always be there. Whether this is done by periodic > advertisement or by triggered route repairs is a matter for further > study. One could imagine similar requirements might be imposed for > important servers in the network (e.g., certificate authority, data > sink, ...). > > I do _not_ think that proactive protocols should automatically be the > choice for mesh backbone routers. Certainly not for all mesh > clients...! I would really question whether it is needed for all > other mesh points anyway. Plus, the whole concept gets quite fuzzy > if there are intermittent long-range connections to neighboring > meshes (as an example). > > Regarding the naming of AODV vs. DYMO: this is a long story with as > much political as technical content, and for my own part the former > was by far the more persuasive factor to persuade me to agree to a > new name for the standards-track reactive protocol. Now the downside > is that we have exactly the confusion in evidence currently for > newly interested parties. Perhaps we should rename DYMO to be AODVv2 > :-) > > Finally, regarding: >> I think each protocol and its supporters can easily make a case >> where it will beat other protocols. Simply look at conference >> publications for good examples. > Simply stated: caveat emptor. > > Stated more verbosely and redundantly using more words and so on... > ---> it is very important to fully understand the range of > applicability for each research result. These are sometimes not > stated very clearly. It is also very helpful, when possible, to > understand the motivations of the authors. > > Regards, Charlie P. > > > ext Ian Chakeres wrote: >> There is no winner takes all in the contest of routing protocols >> for MANET. I think each protocol and its supporters can easily make >> a case where it will beat other protocols. Simply look at >> conference publications for good examples. >> >> That said, we have chosen to standardize DYMO and OLSRv2 - one >> reactive and one reactive protocol in the MANET WG. For more >> information regarding when one might deploy one or the other, >> please see the applicability statements in the drafts. >> >> DYMO is a successor to AODV (and other reactive protocols). The >> specification is chartered to become a proposed standard. AODV is >> not being actively discussed or standardized in the WG. >> >> Ian >> >> On 6/6/07, David Murray <30179198@student.murdoch.edu.au> wrote: >>> Hi, >>> >>> I am wondering how DYMO fits in with the other routing protocols. >>> I have read a number of papers that discuss how on-demand >>> routing protocols like DSR/AODV work better in highly mobile >>> environments where movement is fast, CPU and memory are low and >>> batteries are limited. Equally, in situations where movement is >>> very low, and there are no power limitations, protocols like >>> OLSR/TBRPF/STAR perform better. >>> >>> So, I have a mental picture of OLSR/TBRPF being predominantly >>> used in stationary 802.11 mesh devices and AODV/DYMO being used >>> to connect users mobile devices ush as phones and PDAs. Is this >>> correct or are things not quite as simple as this? (I know RFC >>> 2501 discusses MANET applications and characteristics but the >>> discussion is quite general) >>> >>> If this is correct, it seems to me that DYMO and AODV are used in >>> very similar situations (the ad hoc interconnect between users >>> devices). I am aware that DYMO is a simplified version of AODV >>> both in code and network operation. It seems like the major >>> difference is the path accumulation feature in DYMO which allows >>> nodes to append their information to a RREP to give other nodes >>> better knowledge of the topology. It also seems that the hello >>> feature has been removed in DYMO. So, is DYMO likely to be a >>> replacement for AODV or do they have different uses/applications? >>> >>> >>> >>> >>> Thanks for your time >>> >>> Dave >>> >>> >>> _______________________________________________ manet mailing >>> list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >>> >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 07:12:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcOB-0007s9-Nx; Fri, 08 Jun 2007 07:12:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HwcO9-0007of-Cs for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 07:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcO9-0007oX-3O for manet@ietf.org; Fri, 08 Jun 2007 07:12:17 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcO7-0001nQ-Lz for manet@ietf.org; Fri, 08 Jun 2007 07:12:17 -0400 Received: from [192.168.112.191] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l58BCEI4023925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2007 13:12:14 +0200 Message-ID: <4669398E.1030304@inria.fr> Date: Fri, 08 Jun 2007 13:12:14 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: David Murray <30179198@student.murdoch.edu.au> Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> In-Reply-To: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 4669398E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l58BCEI4023925 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would say that from a very broad perspective, on-demand protocols=20 discriminate routes with respect to time and proactive protocols=20 discriminate routes with respect to space. Personnally I have preference=20 to proactive approach because it is richer and gives better internet=20 legacy. Objectively the two approaches have their advantages and=20 drawbacks and the two should be considered. This said, I don't think that on-demand and proactive approaches are=20 represented at the same level in MANET. OLSRv2 has "space" adaptability:=20 i.e algorithms which automatically adapt to space and topology variety,=20 including for instance the MPR mechanism. In DYMO I don't see an=20 equivalent "time" adaptibility that goes beyond the default values in=20 timers. I think this may explain why the protocol performs great in some=20 scenario and very poorly in other. Some adaptability feature in DYMO would be welcome, not necessarily=20 proactive, but at least some memory based feature could help. Philippe David Murray a =E9crit : > Hi, >=20 > I am wondering how DYMO fits in with the other routing protocols. I hav= e=20 > read a number of papers that discuss how on-demand routing protocols=20 > like DSR/AODV work better in highly mobile environments where movement=20 > is fast, CPU and memory are low and batteries are limited. Equally, in=20 > situations where movement is very low, and there are no power=20 > limitations, protocols like OLSR/TBRPF/STAR perform better. >=20 > So, I have a mental picture of OLSR/TBRPF being predominantly used in=20 > stationary 802.11 mesh devices and AODV/DYMO being used to connect user= s=20 > mobile devices ush as phones and PDAs. Is this correct or are things no= t=20 > quite as simple as this? (I know RFC 2501 discusses MANET applications=20 > and characteristics but the discussion is quite general) >=20 > If this is correct, it seems to me that DYMO and AODV are used in very=20 > similar situations (the ad hoc interconnect between users devices). I a= m=20 > aware that DYMO is a simplified version of AODV both in code and networ= k=20 > operation. It seems like the major difference is the path accumulation=20 > feature in DYMO which allows nodes to append their information to a RRE= P=20 > to give other nodes better knowledge of the topology. It also seems tha= t=20 > the hello feature has been removed in DYMO. So, is DYMO likely to be a=20 > replacement for AODV or do they have different uses/applications? >=20 > Thanks for your time >=20 > Dave >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 07:58:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd6n-00054o-8q; Fri, 08 Jun 2007 07:58:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hwd6l-000527-Gi for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 07:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd6l-00051z-6z for manet@ietf.org; Fri, 08 Jun 2007 07:58:23 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwd6i-00080k-SU for manet@ietf.org; Fri, 08 Jun 2007 07:58:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1181303888!17026869!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27332 invoked from network); 8 Jun 2007 11:58:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 8 Jun 2007 11:58:11 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l58Bw3Ot014386; Fri, 8 Jun 2007 04:58:03 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l58Bw2cf009108; Fri, 8 Jun 2007 06:58:02 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l58BvxZP009023; Fri, 8 Jun 2007 06:58:00 -0500 (CDT) Message-ID: <4669443F.9010404@gmail.com> Date: Fri, 08 Jun 2007 13:57:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Philippe Jacquet Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <4669398E.1030304@inria.fr> In-Reply-To: <4669398E.1030304@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000748-0, 07/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Philippe Jacquet wrote: > I would say that from a very broad perspective, on-demand protocols > discriminate routes with respect to time and proactive protocols > discriminate routes with respect to space. Personnally I have > preference to proactive approach because it is richer and gives > better internet legacy. Objectively the two approaches have their > advantages and drawbacks and the two should be considered. I mostly agree (although I don't see the spatio-temporal discrimination, not even the frequency-temporal :-) I think the classification on-demand vs proactive is conceptual only, helping frame one's mind around two ways of obtaining routes. That classification can't really be used to pit a protocol vs another. OLSRv2 document says it's proactive but I think an OLSRv2 implementation must be able to obtain a route if it receives a app packet whose dst it doesn't know, and if it doesn't have a default route. Making it on-demand. Similary, DYMO says it's on-demand but it should advertise RREP (or RREQs) periodically if it needs to maintain up to date information at all times. Making it reactive. OLSRv2 says it's 'table-driven'. But DYMO uses tables too. Similar things apply to link-state vs distance-vector distinction. I think I personally would like to escape this artificial classification. In my humble oppinion. Alex > > This said, I don't think that on-demand and proactive approaches are > represented at the same level in MANET. OLSRv2 has "space" > adaptability: i.e algorithms which automatically adapt to space and > topology variety, including for instance the MPR mechanism. In DYMO I > don't see an equivalent "time" adaptibility that goes beyond the > default values in timers. I think this may explain why the protocol > performs great in some scenario and very poorly in other. > > Some adaptability feature in DYMO would be welcome, not necessarily > proactive, but at least some memory based feature could help. > > Philippe > > David Murray a écrit : >> Hi, >> >> I am wondering how DYMO fits in with the other routing protocols. I >> have read a number of papers that discuss how on-demand routing >> protocols like DSR/AODV work better in highly mobile environments >> where movement is fast, CPU and memory are low and batteries are >> limited. Equally, in situations where movement is very low, and >> there are no power limitations, protocols like OLSR/TBRPF/STAR >> perform better. >> >> So, I have a mental picture of OLSR/TBRPF being predominantly used >> in stationary 802.11 mesh devices and AODV/DYMO being used to >> connect users mobile devices ush as phones and PDAs. Is this >> correct or are things not quite as simple as this? (I know RFC 2501 >> discusses MANET applications and characteristics but the >> discussion is quite general) >> >> If this is correct, it seems to me that DYMO and AODV are used in >> very similar situations (the ad hoc interconnect between users >> devices). I am aware that DYMO is a simplified version of AODV both >> in code and network operation. It seems like the major difference >> is the path accumulation feature in DYMO which allows nodes to >> append their information to a RREP to give other nodes better >> knowledge of the topology. It also seems that the hello feature has >> been removed in DYMO. So, is DYMO likely to be a replacement for >> AODV or do they have different uses/applications? >> >> Thanks for your time >> >> Dave >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >> >> > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 08:26:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdXu-00018t-OS; Fri, 08 Jun 2007 08:26:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HwdXt-000189-7M for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 08:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdXs-00016A-P8 for manet@ietf.org; Fri, 08 Jun 2007 08:26:24 -0400 Received: from m13-54.163.com ([220.181.13.54]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwdXn-0002dj-7B for manet@ietf.org; Fri, 08 Jun 2007 08:26:24 -0400 Received: from 220.181.12.228 ( 220.181.12.228 [220.181.12.228] ) by ajax-webmail-wmsvr54 (Coremail) ; Fri, 8 Jun 2007 20:26:11 +0800 (CST) Date: Fri, 8 Jun 2007 20:26:11 +0800 (CST) From: "qqq.yinmin" To: manet@ietf.org Message-ID: <16042107.5897961181305571728.JavaMail.coremail@bj163app54.163.com> In-Reply-To: References: MIME-Version: 1.0 X-Originating-IP: [220.181.12.228] X-Priority: 3 X-Mailer: Coremail Webmail Server Version ${coremail.version} build 070313(3236.1034.1035) Copyright (c) 2002-2007 www.mailtech.cn 163com X-Spam-Score: 1.8 (+) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Subject: [manet] Re:manet Digest, Vol 38, Issue 10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1083003232==" Errors-To: manet-bounces@ietf.org --===============1083003232== Content-Type: multipart/Alternative; boundary="----=_Part_637273_3368975.1181305571727" ------=_Part_637273_3368975.1181305571727 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: quoted-printable =20 =D4=DA2007-06-08=A3=ACmanet-request@ietf.org =D0=B4=B5=C0=A3=BA Send manet mailing list submissions to manet@ietf.org To subscribe or unsub= scribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo= /manet or, via email, send a message with subject or body 'help' to manet-r= equest@ietf.org You can reach the person managing the list at manet-owner@i= etf.org When replying, please edit your Subject line so it is more specific= than "Re: Contents of manet digest..." Today's Topics: 1. Re: DYMO and oth= er routing protocols (Charles E. Perkins) ---------------------------------= ------------------------------------- Message: 1 Date: Wed, 06 Jun 2007 11:= 40:05 -0700 From: "Charles E. Perkins" Subject:= Re: [manet] DYMO and other routing protocols To: ext Ian Chakeres , David Murray <30179198@student.murdoch.edu.au> Cc: manet@= ietf.org Message-ID: <4666FF85.2040306@nokia.com> Content-Type: text/plain;= charset=3DISO-8859-1; format=3Dflowed Hello folks, I am quite hopeful that= we can get to a converged routing protocol that will subsume the best aspe= cts of DYMO and OLSR. We have many recent results pointing the way forward,= some of which I presented at the last IETF. I am hoping to have a much mor= e complete presentation ready for the next meeting. I think it is clear by = now that proactive protocol operation is better when either there is a stro= ng requirement for minimizing latency in an uncongested network, or when th= e traffic patterns are not very sparse. So, for instance, if most nodes in = an ad hoc network have open communications with most other nodes in the sam= e network, the communication pattern is not at all sparse. The tricky point= is to find out how dense the traffic pattern needs to be in order to favor= proactive operation (or, alternatively, how sparse the traffic has to be i= n order to favor reactive operation). Furthermore, it is quite likely that = some routes should be proactively maintained even if route table entries ar= e generally acquired on demand. The canonical example is that nodes need a = route to a gateway [if one exists] (or default router) often enough that th= e route should always be there. Whether this is done by periodic advertisem= ent or by triggered route repairs is a matter for further study. One could = imagine similar requirements might be imposed for important servers in the = network (e.g., certificate authority, data sink, ...). I do _not_ think tha= t proactive protocols should automatically be the choice for mesh backbone = routers. Certainly not for all mesh clients...! I would really question whe= ther it is needed for all other mesh points anyway. Plus, the whole concept= gets quite fuzzy if there are intermittent long-range connections to neigh= boring meshes (as an example). Regarding the naming of AODV vs. DYMO: this = is a long story with as much political as technical content, and for my own= part the former was by far the more persuasive factor to persuade me to ag= ree to a new name for the standards-track reactive protocol. Now the downsi= de is that we have exactly the confusion in evidence currently for newly in= terested parties. Perhaps we should rename DYMO to be AODVv2 :-) Finally, r= egarding: > I think each protocol and its supporters can easily make a case= > where it will beat other protocols. Simply look at conference > publicat= ions for good examples. Simply stated: caveat emptor. Stated more verbosely= and redundantly using more words and so on... ---> it is very important to= fully understand the range of applicability for each research result. Thes= e are sometimes not stated very clearly. It is also very helpful, when poss= ible, to understand the motivations of the authors. Regards, Charlie P. ext= Ian Chakeres wrote: > There is no winner takes all in the contest of routi= ng protocols for > MANET. I think each protocol and its supporters can easi= ly make a case > where it will beat other protocols. Simply look at confere= nce > publications for good examples. > > That said, we have chosen to stan= dardize DYMO and OLSRv2 - one > reactive and one reactive protocol in the M= ANET WG. For more > information regarding when one might deploy one or the = other, please > see the applicability statements in the drafts. > > DYMO is= a successor to AODV (and other reactive protocols). The > specification is= chartered to become a proposed standard. AODV is not > being actively disc= ussed or standardized in the WG. > > Ian > > On 6/6/07, David Murray <30179= 198@student.murdoch.edu.au> wrote: >> Hi, >> >> I am wondering how DYMO fit= s in with the other routing protocols. I >> have read a number of papers th= at discuss how on-demand routing >> protocols like DSR/AODV work better in = highly mobile environments where >> movement is fast, CPU and memory are lo= w and batteries are limited. >> Equally, in situations where movement is ve= ry low, and there are no >> power limitations, protocols like OLSR/TBRPF/ST= AR perform better. >> >> So, I have a mental picture of OLSR/TBRPF being pr= edominantly used in >> stationary 802.11 mesh devices and AODV/DYMO being u= sed to connect >> users mobile devices ush as phones and PDAs. Is this corr= ect or are >> things not quite as simple as this? (I know RFC 2501 discusse= s MANET >> applications and characteristics but the discussion is quite gen= eral) >> >> If this is correct, it seems to me that DYMO and AODV are used = in very >> similar situations (the ad hoc interconnect between users device= s). I >> am aware that DYMO is a simplified version of AODV both in code an= d >> network operation. It seems like the major difference is the path >> a= ccumulation feature in DYMO which allows nodes to append their >> informati= on to a RREP to give other nodes better knowledge of the >> topology. It al= so seems that the hello feature has been removed in >> DYMO. So, is DYMO li= kely to be a replacement for AODV or do they have >> different uses/applica= tions? >> >> Thanks for your time >> >> Dave >> >> >> _____________________= __________________________ >> manet mailing list >> manet@ietf.org >> https= ://www1.ietf.org/mailman/listinfo/manet >> > > > __________________________= _____________________ > manet mailing list > manet@ietf.org > https://www1.= ietf.org/mailman/listinfo/manet ------------------------------ ____________= ___________________________________ manet mailing list manet@ietf.org https= ://www1.ietf.org/mailman/listinfo/manet End of manet Digest, Vol 38, Issue = 10 ************************************* ------=_Part_637273_3368975.1181305571727 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: quoted-printable
 
 
 
 

=D4=DA2007-06-08=A3=ACmanet-request@ietf.org =D0=B4=B5=C0= =A3=BA
Send manet mailing list submissions to
=09manet@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=09https://www1.ietf.org/mailman/listinfo/manet
or, via email, send a message with subject or body 'help' to
=09manet-request@ietf.org

You can reach the person managing the list at
=09manet-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of manet digest..."


Today's Topics:

   1. Re: DYMO and other routing protocols (Charles E. Perkins)


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

Message: 1
Date: Wed, 06 Jun 2007 11:40:05 -0700
From: "Charles E. Perkins" <charles.perkins@nokia.com>
Subject: Re: [manet] DYMO and other routing protocols
To: ext Ian Chakeres <ian.chakeres@gmail.com>,=09David Murray
=09<30179198@student.murdoch.edu.au>
Cc: manet@ietf.org
Message-ID: <4666FF85.2040306@nokia.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed


Hello folks,

I am quite hopeful that we can get to a converged
routing protocol that will subsume the best aspects
of DYMO and OLSR.  We have many recent
results pointing the way forward, some of which
I presented at the last IETF.  I am hoping to have
a much more complete presentation ready for the
next meeting.

I think it is clear by now that proactive protocol
operation is better when either there is a strong
requirement for minimizing latency in an uncongested
network, or when the traffic patterns are not very
sparse.  So, for instance, if most nodes in an ad
hoc network have open communications with most
other nodes in the same network, the communication
pattern is not at all sparse.  The tricky point is to find
out how dense the traffic pattern needs to be in order
to favor proactive operation (or, alternatively, how
sparse the traffic has to be in order to favor
reactive operation).

Furthermore, it is quite likely that some routes
should be proactively maintained even if route
table entries are generally acquired on demand.
The canonical example is that nodes need a
route to a gateway [if one exists] (or default router)
often enough that the route should always be there.
Whether this is done by periodic advertisement or
by triggered route repairs is a matter for further
study.  One could imagine similar requirements
might be imposed for important servers in the
network (e.g., certificate authority, data sink, ...).

I do _not_ think that proactive protocols should
automatically be the choice for mesh backbone routers.
Certainly not for all mesh clients...!  I would really
question whether it is needed for all other mesh
points anyway.  Plus, the whole concept gets quite
fuzzy if there are intermittent long-range connections
to neighboring meshes (as an example).

Regarding the naming of AODV vs. DYMO: this is
a long story with as much political as technical content,
and for my own part the former was by far the more
persuasive factor to persuade me to agree to a new
name for the standards-track reactive protocol.
Now the downside is that we have exactly the confusion
in evidence currently for newly interested parties.  Perhaps
we should rename DYMO to be AODVv2 :-)

Finally, regarding:
>   I think each protocol and its supporters can easily make a case
> where it will beat other protocols. Simply look at conference
> publications for good examples.
Simply stated: caveat emptor.

Stated more verbosely and redundantly using more words
and so on...
---> it is very important to fully understand the range
         of applicability for each research result.  These are
         sometimes not stated very clearly.  It is also very
         helpful, when possible, to understand the motivations
         of the authors.

Regards,
Charlie P.


ext Ian Chakeres wrote:
> There is no winner takes all in the contest of routing protocols for
> MANET. I think each protocol and its supporters can easily make a case
> where it will beat other protocols. Simply look at conference
> publications for good examples.
>
> That said, we have chosen to standardize DYMO and OLSRv2 - one
> reactive and one reactive protocol in the MANET WG. For more
> information regarding when one might deploy one or the other, please
> see the applicability statements in the drafts.
>
> DYMO is a successor to AODV (and other reactive protocols). The
> specification is chartered to become a proposed standard. AODV is not
> being actively discussed or standardized in the WG.
>
> Ian
>
> On 6/6/07, David Murray <30179198@student.murdoch.edu.au> wrote:
>> Hi,
>>
>> I am wondering how DYMO fits in with the other routing protocols. =
I
>> have read a number of papers that discuss how on-demand routing
>> protocols like DSR/AODV work better in highly mobile environments =
where
>> movement is fast, CPU and memory are low and batteries are limited=
.
>> Equally, in situations where movement is very low, and there are n=
o
>> power limitations, protocols like OLSR/TBRPF/STAR perform better.
>>
>> So, I have a mental picture of OLSR/TBRPF being predominantly used=
 in
>> stationary 802.11 mesh devices and AODV/DYMO being used to connect
>> users mobile devices ush as phones and PDAs. Is this correct or ar=
e
>> things not quite as simple as this? (I know RFC 2501 discusses MAN=
ET
>> applications and characteristics but the discussion is quite gener=
al)
>>
>> If this is correct, it seems to me that DYMO and AODV are used in =
very
>> similar situations (the ad hoc interconnect between users devices)=
. I
>> am aware that DYMO is a simplified version of AODV both in code an=
d
>> network operation. It seems like the major difference is the path
>> accumulation feature in DYMO which allows nodes to append their
>> information to a RREP to give other nodes better knowledge of the
>> topology. It also seems that the hello feature has been removed in
>> DYMO. So, is DYMO likely to be a replacement for AODV or do they h=
ave
>> different uses/applications?
>>
>> Thanks for your time
>>
>> Dave
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www1.ietf.org/mailman/listinfo/manet
>>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet





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

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


End of manet Digest, Vol 38, Issue 10
*************************************


150 =CD= =F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 =D3=CE=A3=AC=C4=E3 =B2= =BB =CA=D4 =CA=D4 =C2=F0 =A3=BF ------=_Part_637273_3368975.1181305571727-- --===============1083003232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1083003232==-- From manet-bounces@ietf.org Fri Jun 08 08:47:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdsF-0002Ks-LU; Fri, 08 Jun 2007 08:47:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HwdsE-0002Kd-DB for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 08:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdsE-0002KT-34 for manet@ietf.org; Fri, 08 Jun 2007 08:47:26 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwdsD-0002hY-4r for manet@ietf.org; Fri, 08 Jun 2007 08:47:26 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l58ClOSx017338 for ; Fri, 8 Jun 2007 13:47:24 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l58ClO96003524 for ; Fri, 8 Jun 2007 13:47:24 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 08 Jun 2007 13:47:24 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 13:47:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Fri, 8 Jun 2007 13:47:23 +0100 Message-ID: In-Reply-To: <4669443F.9010404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DYMO and other routing protocols Thread-Index: AcepxFh9l9Bt++OiQpGdp6zXfIoI+AAAvb8A From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Philippe Jacquet" X-OriginalArrivalTime: 08 Jun 2007 12:47:23.0862 (UTC) FILETIME=[293C4760:01C7A9CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > OLSRv2 document says it's proactive but I think an OLSRv2 implementation > must be able to obtain a route if it receives a app packet whose dst it > doesn't know, and if it doesn't have a default route. Not in that way. Using the protocol as to be standardised, if an OLSR (v1 or v2) node receives a packet from destination it doesn't know, it does nothing to find that route. There is allowed to be responsiveness (a term we use as say reactiveness would be confusing) in the protocol at the signalling level. If an OLSR (v1 or v2) node receives a HELLO message containing information about a neighbour it's never heard of, it doesn't have to maintain its current fixed schedule to send a HELLO message containing this extra information, but can do so early. This will accelerate what you want here, and may even look reactive. But it's more than just subtly different. A node that wants to find node X can't make that happen, it has to wait for node X to inform it (directly or, more usually, via other nodes). > Similary, DYMO says it's on-demand but it should advertise RREP (or > RREQs) periodically if it needs to maintain up to date information at > all times. But maintaining up to date information about all destinations at all times is not necessarily desirable. (Talk to 6LoWPAN people about this, for example.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 11:51:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgkV-0001DC-QD; Fri, 08 Jun 2007 11:51:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HwgkU-0001D2-LZ for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 11:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgkU-0001Co-Bx for manet@ietf.org; Fri, 08 Jun 2007 11:51:38 -0400 Received: from exchange-fe1a.nmsu.edu ([128.123.34.178] helo=exchange-fe1.ACN.ad.nmsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgkS-0007mr-Ny for manet@ietf.org; Fri, 08 Jun 2007 11:51:38 -0400 Received: from EXCHANGE-BE1.ACN.ad.nmsu.edu ([128.123.34.119]) by exchange-fe1.ACN.ad.nmsu.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:51:35 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Fri, 8 Jun 2007 09:51:39 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [manet] DYMO and other routing protocols Thread-index: AcepxFh9l9Bt++OiQpGdp6zXfIoI+AAAvb8AAAZ80CA= References: <4669443F.9010404@gmail.com> From: "Mullen, John" To: X-OriginalArrivalTime: 08 Jun 2007 15:51:35.0821 (UTC) FILETIME=[E4B763D0:01C7A9E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I've been lurking on current topics and agree with most comments. Nevertheless, I decided to peep up. I think, in the end, at the least there will be a common framework for a MANET routing protocol which employs a mix of strategies. A proactive protocol has its advantages, but is not practical for very large networks, due to the fact that the status of a wireless link is often not easily determined and that it takes time for updates to propagate. At some point, few, if any, nodes in the network will have an accurate set of tables and no node will be sure that the data it has is accurate. On top of that, you have bandwidth being used to propagate routing information that may never be used. On the other hand, while on-demand protocols address these issues, there is an initial latency for establishing a new route. In addition, bandwidth is consumed in searches and nodes are not much more confident in their data.=20 In the "real" world, MANETS differ greatly in a number of features, including node density, propagation characteristics, traffic patterns and intensity, etc. In addition, one can expect MANETs to be heterogeneous. There may be a few clusters of nodes in an otherwise sparse network, much like the manner in which human population is distributed. Propagation conditions may vary within the range of the network. Traffic patterns and intensity may change drastically from time to time. While Hello messages can be useful, I think we have to be careful. For several reasons, they can be reliably received over significantly greater distances than data packets. I do think they should be used, but not without some independent assessment of the ability of the connection to transfer data. I suspect that in the end, the design will be to have a table-driven proactive mode for nearby nodes and an on-demand mode for the long haul. It should be relatively easy for nodes to maintain tables of one-hop neighbors and two-hop is not that much more difficult. Clustering is a possible approach here, as well, though it does require a bit more sophistication. If there are also shared records of current long-haul routes, the combination can reduce the time and bandwidth needed to find or repair a route.=20 It took a long time for people to work out the nasty details for radio communications and in the beginning, operators relied on a few basic controls and their skill. Now, we know enough to reliably handle that mess through hardware and software. A basic MANET protocol in which different features can be "tweaked," either manually or through algorithms, would provide a sound basis on which to study the messier problems and, over time, find good solutions. That is, a common protocol would provide a common framework in which to conduct experiments and report results in a manner that all involved could understand and evaluate. Establishing that common protocol would be a giant step in the direction we all want to go. Bye for now, John P. Mullen, Ph.D. (505) 646-2958 jomullen@nmsu.edu =20 -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Friday, June 08, 2007 6:47 AM To: Alexandru Petrescu; Philippe Jacquet Cc: manet@ietf.org Subject: RE: [manet] DYMO and other routing protocols > OLSRv2 document says it's proactive but I think an OLSRv2 implementation > must be able to obtain a route if it receives a app packet whose dst it > doesn't know, and if it doesn't have a default route. Not in that way. Using the protocol as to be standardised, if an OLSR (v1 or v2) node receives a packet from destination it doesn't know, it does nothing to find that route. There is allowed to be responsiveness (a term we use as say reactiveness would be confusing) in the protocol at the signalling level. If an OLSR (v1 or v2) node receives a HELLO message containing information about a neighbour it's never heard of, it doesn't have to maintain its current fixed schedule to send a HELLO message containing this extra information, but can do so early. This will accelerate what you want here, and may even look reactive. But it's more than just subtly different. A node that wants to find node X can't make that happen, it has to wait for node X to inform it (directly or, more usually, via other nodes). > Similary, DYMO says it's on-demand but it should advertise RREP (or > RREQs) periodically if it needs to maintain up to date information at > all times. But maintaining up to date information about all destinations at all times is not necessarily desirable. (Talk to 6LoWPAN people about this, for example.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 15:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjlL-0005ya-FA; Fri, 08 Jun 2007 15:04:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HwjlK-0005yV-L5 for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjlK-0005yN-BH for manet@ietf.org; Fri, 08 Jun 2007 15:04:42 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjlI-0002rG-OE for manet@ietf.org; Fri, 08 Jun 2007 15:04:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l58J4HdX024225; Fri, 8 Jun 2007 22:04:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 22:04:37 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:04:25 -0500 Received: from [172.18.141.144] ([172.18.141.144]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:04:25 -0500 Message-ID: <4669A835.7090004@nokia.com> Date: Fri, 08 Jun 2007 12:04:21 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Philippe Jacquet Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <4669398E.1030304@inria.fr> In-Reply-To: <4669398E.1030304@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 08 Jun 2007 19:04:25.0623 (UTC) FILETIME=[D4DB1270:01C7A9FF] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext13.nokia.com id l58J4HdX024225 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Philippe, I really want to understand your point, but I confess that I am somewhat mystified and not yet getting it. How does OLSR adapt to "space"? Do you mean Euclidean space with constant radio range? I can just see the point about topology (because of MPRs), but I think we should insist that both DYMO and OLSR be equally able to utilize some SMF (or, lately for us, SMURF) ways of flooding over reduced relay sets. As I understand this, the common dependence on a reduced relay set will give both proactive and reactive approaches equal adaptability to topology. But this still doesn't enlighten me about adaptability in space. Regarding the adaptability in time... DYMO has the following time-based dependencies - route timeouts - shifting route discovery anywhere up to and including application launch - some second order effects about sequence numbers. I can definitely see a role for a new extension which enables nodes in a path to specify a non-default value for the route timeout. But it is not clear to me that this is what you are referring to. Could you be a bit more explicit? Anyway, this note is a long way of asking for more details, and I hope you won't mind having a longer discussion about it. Finally, if you would care to point out cases where DYMO performs poorly, but which are not able to be explained by reliance on brute-force flooding, it would be appreciated. I know about the case of fully-connected traffic patterns, and a few other corner cases, but somehow I feel you may have something else in mind. Regards, Charlie P. ext Philippe Jacquet wrote: > I would say that from a very broad perspective, on-demand protocols=20 > discriminate routes with respect to time and proactive protocols=20 > discriminate routes with respect to space. Personnally I have=20 > preference to proactive approach because it is richer and gives better=20 > internet legacy. Objectively the two approaches have their advantages=20 > and drawbacks and the two should be considered. > > This said, I don't think that on-demand and proactive approaches are=20 > represented at the same level in MANET. OLSRv2 has "space"=20 > adaptability: i.e algorithms which automatically adapt to space and=20 > topology variety, including for instance the MPR mechanism. In DYMO I=20 > don't see an equivalent "time" adaptibility that goes beyond the=20 > default values in timers. I think this may explain why the protocol=20 > performs great in some scenario and very poorly in other. > > Some adaptability feature in DYMO would be welcome, not necessarily=20 > proactive, but at least some memory based feature could help. > > Philippe > > David Murray a =E9crit : >> Hi, >> >> I am wondering how DYMO fits in with the other routing protocols. I=20 >> have read a number of papers that discuss how on-demand routing=20 >> protocols like DSR/AODV work better in highly mobile environments=20 >> where movement is fast, CPU and memory are low and batteries are=20 >> limited. Equally, in situations where movement is very low, and there=20 >> are no power limitations, protocols like OLSR/TBRPF/STAR perform bette= r. >> >> So, I have a mental picture of OLSR/TBRPF being predominantly used in=20 >> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >> users mobile devices ush as phones and PDAs. Is this correct or are=20 >> things not quite as simple as this? (I know RFC 2501 discusses MANET=20 >> applications and characteristics but the discussion is quite general) >> >> If this is correct, it seems to me that DYMO and AODV are used in=20 >> very similar situations (the ad hoc interconnect between users=20 >> devices). I am aware that DYMO is a simplified version of AODV both=20 >> in code and network operation. It seems like the major difference is=20 >> the path accumulation feature in DYMO which allows nodes to append=20 >> their information to a RREP to give other nodes better knowledge of=20 >> the topology. It also seems that the hello feature has been removed=20 >> in DYMO. So, is DYMO likely to be a replacement for AODV or do they=20 >> have different uses/applications? >> >> Thanks for your time >> >> Dave >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 15:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwjus-00009z-PQ; Fri, 08 Jun 2007 15:14:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hwjuq-00004q-N0 for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwjuq-0008WN-DV for manet@ietf.org; Fri, 08 Jun 2007 15:14:32 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwjuo-0005HB-Vh for manet@ietf.org; Fri, 08 Jun 2007 15:14:32 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l58JEOLq032397; Fri, 8 Jun 2007 22:14:28 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 22:14:25 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:14:23 -0500 Received: from [172.18.141.144] ([172.18.141.144]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:14:23 -0500 Message-ID: <4669AA8E.8040806@nokia.com> Date: Fri, 08 Jun 2007 12:14:22 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Alexandru Petrescu Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <4669398E.1030304@inria.fr> <4669443F.9010404@gmail.com> In-Reply-To: <4669443F.9010404@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 19:14:23.0740 (UTC) FILETIME=[395C7BC0:01C7AA01] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Alexandru, ext Alexandru Petrescu wrote: > I think the classification on-demand vs proactive is conceptual only, > helping frame one's mind around two ways of obtaining routes. Well, leaving aside the notion that all work in the IETF is conceptual only, I am not sure just what you mean. In my view, on-demand routing is one of the main contributions of [manet] to routing technology. > > That classification can't really be used to pit a protocol vs another. It has proved to be a very useful conceptual tool, helping a lot of people organize their thoughts about the way protocols work. > Similary, DYMO says it's on-demand but it should advertise RREP (or > RREQs) periodically if it needs to maintain up to date information at > all times. Making it reactive. I know you meant "proactive". This is not in the protocol specification, but for some particular cases I quite agree. A better example would be "HELLO" messaging. Generally speaking, just because two classifications are not mathematically contradictory, does not make them useless -- right?? We use blue and green to describe things as needed, and no one complains based on the existence of turquoise or aqua. If you would rephrase your point to instead say that we should avoid being constrained by the way we have classified things in the past, I would very much agree with you. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 15:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwk5K-0001KV-HM; Fri, 08 Jun 2007 15:25:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hwk5I-0001Ea-8A for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwk5F-0001DL-Vp for manet@ietf.org; Fri, 08 Jun 2007 15:25:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwk5F-0004Nn-D7 for manet@ietf.org; Fri, 08 Jun 2007 15:25:17 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2007 12:25:17 -0700 X-IronPort-AV: i="4.16,400,1175497200"; d="scan'208"; a="378127713:sNHT52743022" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l58JPGWB032104; Fri, 8 Jun 2007 12:25:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l58JPAaK009898; Fri, 8 Jun 2007 19:25:14 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:25:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Fri, 8 Jun 2007 12:25:37 -0700 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A0264B34D@xmb-sjc-219.amer.cisco.com> In-Reply-To: <4669398E.1030304@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DYMO and other routing protocols Thread-Index: AcepvemG09QcwVTYQa6on+urBcffPgAQrvZw From: "Krishna Sankar \(ksankar\)" To: "Philippe Jacquet" , "David Murray" <30179198@student.murdoch.edu.au> X-OriginalArrivalTime: 08 Jun 2007 19:25:09.0833 (UTC) FILETIME=[BA767390:01C7AA02] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4680; t=1181330716; x=1182194716; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ksankar@cisco.com; z=From:=20=22Krishna=20Sankar=20\(ksankar\)=22=20 |Subject:=20RE=3A=20[manet]=20DYMO=20and=20other=20routing=20protocols |Sender:=20; bh=ld9ul+aF8llZ7b5klWshqWnlX/S7NNmat7I4QIPh65w=; b=Rf6Y6gbFbIzo6Eeg7ywmsLyU+R/MZ/qVzapIw1IE5jPMOntlIk5HrP8rQ9LAcVIXr04gG3DQ YYnOJLpxT5s5aHc0O9aaBCeBfOWZg+H562+s7xHqZjIhJDmdXwLy9UZb; Authentication-Results: sj-dkim-4; header.From=ksankar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Philippe, Interesting discussions. Couple of questions: > space. Personally I have preference to proactive approach=20 > because it is richer and gives better internet legacy.=20 I would argue exactly the opposite - reactive protocols are more = "internet-native". Let me explain: a) In internet you resolve end point locations thru DNS (and optimize = it by caching and querying when a cache is invalid, one does not query = every time nor one has all the resolution database locally) b) Naturally internet is packet based not circuit based c) The routes do change based on congestion, peering, even optimized = edge routing and multi topology routing based on declarative policies = and "coloring" =20 > Some adaptability feature in DYMO would be welcome, not=20 > necessarily proactive, but at least some memory based feature=20 > could help. Are you talking about spatial interpolation based on history ? Mobility = algorithmics based on 1st and 2nd order derivatives of mobility vectors = - For example if we know a node is moving, if we can infer the = acceleration and also the spatial topology, we could possibly say where = it could be and what the route could be knowing the nodes in that = vicinity ... Cheers > -----Original Message----- > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 > Sent: Friday, June 08, 2007 4:12 AM > To: David Murray > Cc: manet@ietf.org > Subject: Re: [manet] DYMO and other routing protocols >=20 > I would say that from a very broad perspective, on-demand=20 > protocols discriminate routes with respect to time and=20 > proactive protocols discriminate routes with respect to=20 > space. Personnally I have preference to proactive approach=20 > because it is richer and gives better internet legacy.=20 > Objectively the two approaches have their advantages and=20 > drawbacks and the two should be considered. >=20 > This said, I don't think that on-demand and proactive=20 > approaches are represented at the same level in MANET. OLSRv2=20 > has "space" adaptability:=20 > i.e algorithms which automatically adapt to space and=20 > topology variety, including for instance the MPR mechanism.=20 > In DYMO I don't see an equivalent "time" adaptibility that=20 > goes beyond the default values in timers. I think this may=20 > explain why the protocol performs great in some scenario and=20 > very poorly in other. >=20 > Some adaptability feature in DYMO would be welcome, not=20 > necessarily proactive, but at least some memory based feature=20 > could help. >=20 > Philippe >=20 > David Murray a =E9crit : > > Hi, > >=20 > > I am wondering how DYMO fits in with the other routing protocols. I=20 > > have read a number of papers that discuss how on-demand routing=20 > > protocols like DSR/AODV work better in highly mobile environments=20 > > where movement is fast, CPU and memory are low and batteries are=20 > > limited. Equally, in situations where movement is very low,=20 > and there=20 > > are no power limitations, protocols like OLSR/TBRPF/STAR=20 > perform better. > >=20 > > So, I have a mental picture of OLSR/TBRPF being=20 > predominantly used in=20 > > stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 > > users mobile devices ush as phones and PDAs. Is this correct or are=20 > > things not quite as simple as this? (I know RFC 2501=20 > discusses MANET=20 > > applications and characteristics but the discussion is=20 > quite general) > >=20 > > If this is correct, it seems to me that DYMO and AODV are=20 > used in very=20 > > similar situations (the ad hoc interconnect between users=20 > devices). I=20 > > am aware that DYMO is a simplified version of AODV both in code and=20 > > network operation. It seems like the major difference is the path=20 > > accumulation feature in DYMO which allows nodes to append their=20 > > information to a RREP to give other nodes better knowledge of the=20 > > topology. It also seems that the hello feature has been removed in=20 > > DYMO. So, is DYMO likely to be a replacement for AODV or do=20 > they have different uses/applications? > >=20 > > Thanks for your time > >=20 > > Dave > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 > >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 08 15:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkEY-0001LQ-GJ; Fri, 08 Jun 2007 15:34:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HwkEW-0001LK-0M for manet-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkEV-0001L9-N3 for manet@ietf.org; Fri, 08 Jun 2007 15:34:51 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkEU-0000jf-9N for manet@ietf.org; Fri, 08 Jun 2007 15:34:51 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l58JYW8t024865; Fri, 8 Jun 2007 22:34:45 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 22:34:38 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:34:03 -0500 Received: from [172.18.141.144] ([172.18.141.144]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:34:03 -0500 Message-ID: <4669AF29.1050901@nokia.com> Date: Fri, 08 Jun 2007 12:34:01 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ext Mullen, John" Subject: Re: [manet] DYMO and other routing protocols References: <4669443F.9010404@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 19:34:03.0130 (UTC) FILETIME=[F8551DA0:01C7AA03] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello John, ext Mullen, John wrote: > I think, in the end, at the least there will be a common framework for a > MANET routing protocol which employs a mix of strategies. In the new millenium, "framework" is a derogatory term (isn't it?). I reckon it would be better to position such an effort as a hybridized or parameterized protocol, which activates perhaps somewhat different "strategies" (i.e., protocol messages) depending on the recent state of the network -- or alternatively based on application requirements. > ... no node will be sure that the data it has is accurate. > Mobility ==> inaccuracy, to a very large extent. Some approaches use velocity information to place a bound on the inaccuracy, but these have had variable success. So I don't think we can achieve the goal of enabling nodes to have complete "confidence". But we can devise strategies so that nodes can recover from error conditions. > ... Establishing that common protocol would be a giant step in the > direction we all want to go. > I think we know enough to start pursuing this goal, but on the other hand such an effort should be managed very carefully so that we do not impede progress towards achieving our current charter items. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Jun 10 10:38:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxOYs-0003WM-50; Sun, 10 Jun 2007 10:38:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxOYq-0003WH-Fc for manet-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 10:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxOYq-0003W9-5z for manet@ietf.org; Sun, 10 Jun 2007 10:38:32 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxOYn-0003gs-Pi for manet@ietf.org; Sun, 10 Jun 2007 10:38:32 -0400 Received: from eesun1.tamu.edu (eesun1.tamu.edu [165.91.243.35]) by ee.tamu.edu (8.13.6/8.13.6) with ESMTP id l5AEbQWA027465; Sun, 10 Jun 2007 09:37:27 -0500 (CDT) Date: Sun, 10 Jun 2007 09:37:26 -0500 (CDT) From: Xi Zhang X-Sender: xizhang@eesun1.tamu.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [manet] ACM/IEEE QShine 2007 Call for Participations. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org #### Sorry for receiving multiple copies #### ACM/IEEE QShine 2007 Call for Participations. ************************************ Call for Participation ACM/IEEE QShine 2007 Vancouver, British Columbia, Canada August 14 - 17, 2007 http://www.qshine.org/index.shtml ************************************ Conference Technical Sponsors: QShine 2007 is in-cooperation with ACM SIGMM, SIGMOBILE, and SIGSIM, and technically co-sponsored by IEEE Communications Society, and Create-Net and ICST. Conference Overview: You are cordially invited to participate in the upcoming 4th ACM/IEEE International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness (ACM/IEEE QShine 2007). The aim of this conference is to bring together research and practitioners to present and share the latest results in the areas of performance, configuration, cross-layer approaches, scalability, resilience and survivability of large scale heterogeneous networks and distributed systems. Following the tradition of the previous QShine meetings, QShine 2007 will feature prominent invited speakers as well as papers by top researchers in the field. QShine 2007 Keynote Speakers: Three renowned world-class areas leaders will provide keynote talks: (1) Dr. Victor Bahl, Microsoft Research; (2) Prof. P. R. Kumar, Franklin Woeltge Professor of Electrical and Computer Engineering Research Professor, Coordinated Science Lab, University of Illinois, Urbana-Champaign; (3) Prof. Kang G. Shin, Kevin & Nancy O'Connor Professor of Computer Science CSE Division, Department of EECS, The University of Michigan. QShine 2007 Registration: Registration can be completed online at https://icst.org/registration/reg_qshine_2007.php. Early registration deadline is July 14, 2007, 23:59 (GMT). QShine 2007 Conference Site: Situated along British Columbia's coastline, Vancouver is a 'Pacific Pearl'. Lying between the Coast Mountain range and the Pacific Ocean, Vancouver is one of the most scenic cities in the world. Vancouver's mild temperatures and bounty of rain are also owed to its location, making even the most urban of areas lush year round. Vancouver appeals to millions of denizens and visitors who bask in all it offers, from its soothing beaches to its bustling streets. For more information about Vancouver see http://www.tourismvancouver.com/visitors/ We are looking forward to seeing you in ACM/IEEE QShine 2007, Vancouver, British Columbia, Canada! QShine 2007 Organizing Committee: General Chair Victor C. M. Leung, University of British Columbia, Canada General Vice-Chair Sastri Kota, Harris Corporation, USA Steering Committee Imrich Chlamtac, (Co-Chair) CreateNet, Italy Michael Fang, (Co-Chair) University of Florida, USA Xuemin (Sherman) Shen, (Co-Chair) University of Waterloo, Canada, Hisashi Kobayashi, Princeton University, USA Ariel Orda, Technion, Israel TPC Co-Chairs Guoliang Xue Arizona State University, USA Jelena Misic, University of Manitoba, Canada Publicity Chair Xi Zhang, Texas A&M University, USA Local Arrangement Chair Lin Cai, University of Victoria, Canada Workshop Chair Giovanni Giambene, Universita' degli Studi di Siena, Italy Poster Chair Ekram Hossain, University of Manitoba, Canada Sponsorship Chair Panos Nasiopoulos, University of British Columbia, Canada Publications Chair Qian Zhang, Hong Kong University of Science and Technology, China Conference Coordination and Registration Kitti H. Kovacs, ICST, USA Finance Chair Karen Decker, ICST, USA ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Jun 10 14:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxSJT-0001Rv-P7; Sun, 10 Jun 2007 14:38:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxSJQ-0001Rp-Nl for manet-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 14:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxSJQ-0001Rh-ED for manet@ietf.org; Sun, 10 Jun 2007 14:38:52 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxSJP-00007B-1w for manet@ietf.org; Sun, 10 Jun 2007 14:38:52 -0400 Received: from ECE149 (ece149.tamu.edu [165.91.208.72]) by ee.tamu.edu (8.13.6/8.13.6) with SMTP id l5AIcGZp007341; Sun, 10 Jun 2007 13:38:17 -0500 (CDT) Message-ID: <003001c7ab96$eb8478c0$48d05ba5@ECE149> From: "Dr. Xi Zhang" To: Date: Sun, 10 Jun 2007 13:38:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [manet] ACM/IEEE QShine 2007 Call for Participations. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org #### Sorry for receiving multiple copies #### ACM/IEEE QShine 2007 Call for Participations. ************************************ Call for Participation ACM/IEEE QShine 2007 Vancouver, British Columbia, Canada August 14 - 17, 2007 http://www.qshine.org/index.shtml ************************************ Conference Technical Sponsors: QShine 2007 is in-cooperation with ACM SIGMM, SIGMOBILE, and SIGSIM, and technically co-sponsored by IEEE Communications Society, and Create-Net and ICST. Conference Overview: You are cordially invited to participate in the upcoming 4th ACM/IEEE International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness (ACM/IEEE QShine 2007). The aim of this conference is to bring together research and practitioners to present and share the latest results in the areas of performance, configuration, cross-layer approaches, scalability, resilience and survivability of large scale heterogeneous networks and distributed systems. Following the tradition of the previous QShine meetings, QShine 2007 will feature prominent invited speakers as well as papers by top researchers in the field. QShine 2007 Keynote Speakers: Three renowned world-class areas leaders will provide keynote talks: (1) Dr. Victor Bahl, Microsoft Research; (2) Prof. P. R. Kumar, Franklin Woeltge Professor of Electrical and Computer Engineering Research Professor, Coordinated Science Lab, University of Illinois, Urbana-Champaign; (3) Prof. Kang G. Shin, Kevin & Nancy O'Connor Professor of Computer Science CSE Division, Department of EECS, The University of Michigan. QShine 2007 Registration: Registration can be completed online at https://icst.org/registration/reg_qshine_2007.php. Early registration deadline is July 14, 2007, 23:59 (GMT). QShine 2007 Conference Site: Situated along British Columbia's coastline, Vancouver is a 'Pacific Pearl'. Lying between the Coast Mountain range and the Pacific Ocean, Vancouver is one of the most scenic cities in the world. Vancouver's mild temperatures and bounty of rain are also owed to its location, making even the most urban of areas lush year round. Vancouver appeals to millions of denizens and visitors who bask in all it offers, from its soothing beaches to its bustling streets. For more information about Vancouver see http://www.tourismvancouver.com/visitors/ We are looking forward to seeing you in ACM/IEEE QShine 2007, Vancouver, British Columbia, Canada! QShine 2007 Organizing Committee: General Chair Victor C. M. Leung, University of British Columbia, Canada General Vice-Chair Sastri Kota, Harris Corporation, USA Steering Committee Imrich Chlamtac, (Co-Chair) CreateNet, Italy Michael Fang, (Co-Chair) University of Florida, USA Xuemin (Sherman) Shen, (Co-Chair) University of Waterloo, Canada, Hisashi Kobayashi, Princeton University, USA Ariel Orda, Technion, Israel TPC Co-Chairs Guoliang Xue Arizona State University, USA Jelena Misic, University of Manitoba, Canada Publicity Chair Xi Zhang, Texas A&M University, USA Local Arrangement Chair Lin Cai, University of Victoria, Canada Workshop Chair Giovanni Giambene, Universita' degli Studi di Siena, Italy Poster Chair Ekram Hossain, University of Manitoba, Canada Sponsorship Chair Panos Nasiopoulos, University of British Columbia, Canada Publications Chair Qian Zhang, Hong Kong University of Science and Technology, China Conference Coordination and Registration Kitti H. Kovacs, ICST, USA Finance Chair Karen Decker, ICST, USA ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 05:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgZf-0004W5-7u; Mon, 11 Jun 2007 05:52:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxgZd-0004IC-5U for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 05:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgZc-0004Fz-PG for manet@ietf.org; Mon, 11 Jun 2007 05:52:32 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxgZa-0006NG-Fi for manet@ietf.org; Mon, 11 Jun 2007 05:52:32 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1181555549!22872328!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19896 invoked from network); 11 Jun 2007 09:52:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 11 Jun 2007 09:52:29 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5B9qSPS011048; Mon, 11 Jun 2007 02:52:29 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5B9qSfG020001; Mon, 11 Jun 2007 04:52:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5B9qQZE019982; Mon, 11 Jun 2007 04:52:26 -0500 (CDT) Message-ID: <466D1B59.2060502@gmail.com> Date: Mon, 11 Jun 2007 11:52:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <4669398E.1030304@inria.fr> <4669443F.9010404@gmail.com> <4669AA8E.8040806@nokia.com> In-Reply-To: <4669AA8E.8040806@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-2, 09/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charles E. Perkins wrote: > > Hello Alexandru, > > ext Alexandru Petrescu wrote: >> I think the classification on-demand vs proactive is conceptual >> only, helping frame one's mind around two ways of obtaining routes. >> >> > > Well, leaving aside the notion that all work in the IETF is > conceptual only, I am not sure just what you mean. In my view, > on-demand routing is one of the main contributions of [manet] to > routing technology. Yes, that notion not purposefully stressed, I mean that it does not make sense to push two different protocols just because the conceptual distinction makes sense. On-demand routing (create routing data at most or all intermediary nodes onyl when end nodes need to communicate) seems to me indeed to be a main contribution of IETF manet to routing technology. It is different than other IETF routing in that it can accommodate potentially very variable topologies. >> That classification can't really be used to pit a protocol vs >> another. > > It has proved to be a very useful conceptual tool, helping a lot of > people organize their thoughts about the way protocols work. I think yes. >> Similary, DYMO says it's on-demand but it should advertise RREP (or >> RREQs) periodically if it needs to maintain up to date information >> at all times. Making it reactive. > > I know you meant "proactive". This is not in the protocol > specification, but for some particular cases I quite agree. A better > example would be "HELLO" messaging. I think we talk here about a proactive need. I take your mentioning of HELLO just an example of semantics. I see very well either OLSR's HELLO, or periodic RREP, or ND's RAs used for proactive needs. > Generally speaking, just because two classifications are not > mathematically contradictory, does not make them useless -- right?? Right. They are useful so we can characterize behaviours. But this classification shouldn't entrench one into thinking a certain protocol can't be both proactive and reactive (some times so other times so). > We use blue and green to describe things as needed, and no one > complains based on the existence of turquoise or aqua. If you would > rephrase your point to instead say that we should avoid being > constrained by the way we have classified things in the past, I would > very much agree with you. I agree, I will rephrase my point to say a protocol can be acqua some times blue other times green. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 06:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgoK-0007ba-II; Mon, 11 Jun 2007 06:07:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxgoJ-0007VC-48 for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 06:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgoI-0007TG-PA for manet@ietf.org; Mon, 11 Jun 2007 06:07:42 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxgoH-00023d-A5 for manet@ietf.org; Mon, 11 Jun 2007 06:07:42 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5BA7dZU002660 for ; Mon, 11 Jun 2007 11:07:39 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5BA7dVV015352 for ; Mon, 11 Jun 2007 11:07:39 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 11 Jun 2007 11:07:38 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 11:07:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Mon, 11 Jun 2007 11:07:37 +0100 Message-ID: In-Reply-To: <4669AF29.1050901@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DYMO and other routing protocols Thread-Index: AceqBBn/xTNwh6WTQ968lFog7vBE6wCC+6Zw From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" , "ext Mullen, John" X-OriginalArrivalTime: 11 Jun 2007 10:07:38.0480 (UTC) FILETIME=[57244F00:01C7AC10] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I think we know enough to start pursuing this goal, but on the > other hand such an effort should be managed very carefully > so that we do not impede progress towards achieving our > current charter items. Definitely agree with both parts of this. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 06:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxgtv-0004o7-9S; Mon, 11 Jun 2007 06:13:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hxgtt-0004o2-Cd for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 06:13:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxgtt-0004nr-2y for manet@ietf.org; Mon, 11 Jun 2007 06:13:29 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hxgtr-0003xg-Jh for manet@ietf.org; Mon, 11 Jun 2007 06:13:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1181556806!1325067!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 22764 invoked from network); 11 Jun 2007 10:13:26 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-3.tower-153.messagelabs.com with SMTP; 11 Jun 2007 10:13:26 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l5BADPA6024719; Mon, 11 Jun 2007 03:13:25 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5BADOL8009949; Mon, 11 Jun 2007 05:13:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5BADLLI009926; Mon, 11 Jun 2007 05:13:22 -0500 (CDT) Message-ID: <466D2041.2020203@gmail.com> Date: Mon, 11 Jun 2007 12:13:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Krishna Sankar (ksankar)" References: <9FA16888AD1BF64ABCE6C2532CCEB98A0264B34D@xmb-sjc-219.amer.cisco.com> In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A0264B34D@xmb-sjc-219.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000748-2, 09/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Philippe Jacquet , manet@ietf.org Subject: [manet] Re: mobility physics and mathematics (was: manet] DYMO and other routing protocols) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Krishna Sankar (ksankar) wrote: >> Some adaptability feature in DYMO would be welcome, not necessarily >> proactive, but at least some memory based feature could help. > > Are you talking about spatial interpolation based on history ? > Mobility algorithmics based on 1st and 2nd order derivatives of > mobility vectors - For example if we know a node is moving, if we can > infer the acceleration and also the spatial topology, we could > possibly say where it could be and what the route could be knowing > the nodes in that vicinity ... It sounds logic to use the expected future physical position as an indicator of where the node is. However, this line of thought is very daring and prone to deep disappointments when tried in IP practice. Because it misses the all-important point that 'mobility' as when an object moves, or as when we draw Brownian dots on paper, is very much different than 'mobility' as implemented in C on some computers. This difference is easily illustrated by the speed paradox of a vehicle moving very fast (130kmph) but whose IP address changes very slow (5 changes per hour). Thus, if we define 'mobility' as the speed at which a node changes its address then (1) we're out of MANET scope because in MANET nodes don't dynamically change their addresses and (2) one realizes physical location ("space") has no relationship whatsoever with an IP address, and interpolating a set of physical coordinates can't result into an IP address whatever trick one applies. I think in order to be able to use the interpolation mathematical tool in the MANET context one has to agree on how routes are represented at intermediary nodes, and how they vary. That agreement is difficult to obtain, to start with. Then I am almost sure route variation (routing table changes) can not be expressed mathematically as function of 'space' co-ordinates. Or if it were then it couldn't easily be grasped by a programmer's mind. That's why I think space can not fit here. But then people are of course free to understand whatever they want by 'space' as people understand whatever they want by 'color'. Alex > > Cheers >> -----Original Message----- From: Philippe Jacquet >> [mailto:philippe.jacquet@inria.fr] Sent: Friday, June 08, 2007 4:12 >> AM To: David Murray Cc: manet@ietf.org Subject: Re: [manet] DYMO >> and other routing protocols >> >> I would say that from a very broad perspective, on-demand protocols >> discriminate routes with respect to time and proactive protocols >> discriminate routes with respect to space. Personnally I have >> preference to proactive approach because it is richer and gives >> better internet legacy. Objectively the two approaches have their >> advantages and drawbacks and the two should be considered. >> >> This said, I don't think that on-demand and proactive approaches >> are represented at the same level in MANET. OLSRv2 has "space" >> adaptability: i.e algorithms which automatically adapt to space and >> topology variety, including for instance the MPR mechanism. In >> DYMO I don't see an equivalent "time" adaptibility that goes beyond >> the default values in timers. I think this may explain why the >> protocol performs great in some scenario and very poorly in other. >> >> Some adaptability feature in DYMO would be welcome, not necessarily >> proactive, but at least some memory based feature could help. >> >> Philippe >> >> David Murray a écrit : >>> Hi, >>> >>> I am wondering how DYMO fits in with the other routing protocols. >>> I have read a number of papers that discuss how on-demand >>> routing protocols like DSR/AODV work better in highly mobile >>> environments where movement is fast, CPU and memory are low and >>> batteries are limited. Equally, in situations where movement is >>> very low, >> and there >>> are no power limitations, protocols like OLSR/TBRPF/STAR >> perform better. >>> So, I have a mental picture of OLSR/TBRPF being >> predominantly used in >>> stationary 802.11 mesh devices and AODV/DYMO being used to >>> connect users mobile devices ush as phones and PDAs. Is this >>> correct or are things not quite as simple as this? (I know RFC >>> 2501 >> discusses MANET >>> applications and characteristics but the discussion is >> quite general) >>> If this is correct, it seems to me that DYMO and AODV are >> used in very >>> similar situations (the ad hoc interconnect between users >> devices). I >>> am aware that DYMO is a simplified version of AODV both in code >>> and network operation. It seems like the major difference is the >>> path accumulation feature in DYMO which allows nodes to append >>> their information to a RREP to give other nodes better knowledge >>> of the topology. It also seems that the hello feature has been >>> removed in DYMO. So, is DYMO likely to be a replacement for AODV >>> or do >> they have different uses/applications? >>> Thanks for your time >>> >>> Dave >>> >>> >>> _______________________________________________ manet mailing >>> list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >>> >>> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 06:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxh7T-0008Nn-BL; Mon, 11 Jun 2007 06:27:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hxh7R-0008Ni-MX for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 06:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxh7Q-0008Na-9t for manet@ietf.org; Mon, 11 Jun 2007 06:27:29 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxh7O-0007N6-T6 for manet@ietf.org; Mon, 11 Jun 2007 06:27:28 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5BARQbv014934 for ; Mon, 11 Jun 2007 11:27:26 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5BARPLe028360 for ; Mon, 11 Jun 2007 11:27:25 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 11 Jun 2007 11:27:24 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 11:27:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: mobility physics and mathematics (was: manet] DYMO andother routing protocols) Date: Mon, 11 Jun 2007 11:27:24 +0100 Message-ID: In-Reply-To: <466D2041.2020203@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: mobility physics and mathematics (was: manet] DYMO andother routing protocols) Thread-Index: AcesES0jhAXBB4W2TrqE+Ps3fg+iXQAAB0+A From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Krishna Sankar \(ksankar\)" X-OriginalArrivalTime: 11 Jun 2007 10:27:24.0785 (UTC) FILETIME=[1A3C1610:01C7AC13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Philippe Jacquet , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > In MANET nodes don't dynamically change their addresses Actually, in anticipation of possible needs for this in some MANETs (using some possible autoconf mechanisms for example) some support is included in NHDP - not mechanisms for deciding on address changes, but "if you change your address(es) for reasons outside the scope of NHDP then do this" and some parts of HELLO processing that may look like "why check that?" but are there to avoid badly behaving neighbours creating inconsistencies in your information repository. Of course in the former case if you don't ever change your addresses, you don't need to ever do anything about it. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 06:38:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhI2-0005oO-95; Mon, 11 Jun 2007 06:38:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxhI0-0005oH-Nu for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 06:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhHz-0005o9-Gv for manet@ietf.org; Mon, 11 Jun 2007 06:38:24 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxhHx-00021U-0x for manet@ietf.org; Mon, 11 Jun 2007 06:38:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1181558300!22874081!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14984 invoked from network); 11 Jun 2007 10:38:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 11 Jun 2007 10:38:20 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5BAcKfN021685; Mon, 11 Jun 2007 03:38:20 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5BAcJI3000577; Mon, 11 Jun 2007 05:38:19 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5BAcHsm000563; Mon, 11 Jun 2007 05:38:18 -0500 (CDT) Message-ID: <466D261A.8030409@gmail.com> Date: Mon, 11 Jun 2007 12:38:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Re: mobility physics and mathematics (was: manet] DYMO andother routing protocols) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-2, 09/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Philippe Jacquet , manet@ietf.org, "Krishna Sankar \(ksankar\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> In MANET nodes don't dynamically change their addresses > > Actually, in anticipation of possible needs for this in > some MANETs (using some possible autoconf mechanisms for > example) some support is included in NHDP - not mechanisms > for deciding on address changes, but "if you change your > address(es) for reasons outside the scope of NHDP then do > this" Hi Christophe, I'm wondering whether NHDP should recommend the use Mobile IP when MANET nodes change their addresses (in addition to recommending sending new HELLO messages). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 06:46:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhPm-00084h-7q; Mon, 11 Jun 2007 06:46:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxhPk-0007wW-6H for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 06:46:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhPj-0007wO-T0 for manet@ietf.org; Mon, 11 Jun 2007 06:46:23 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxhPj-000630-Id for manet@ietf.org; Mon, 11 Jun 2007 06:46:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1181558782!1320301!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 10522 invoked from network); 11 Jun 2007 10:46:22 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-153.messagelabs.com with SMTP; 11 Jun 2007 10:46:22 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l5BAkLhO021800; Mon, 11 Jun 2007 03:46:21 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5BAkLXS022976; Mon, 11 Jun 2007 05:46:21 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5BAkI52022948; Mon, 11 Jun 2007 05:46:19 -0500 (CDT) Message-ID: <466D27FB.9000106@gmail.com> Date: Mon, 11 Jun 2007 12:46:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] DYMO and other routing protocols References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-2, 09/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Philippe Jacquet , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> OLSRv2 document says it's proactive but I think an OLSRv2 >> implementation must be able to obtain a route if it receives a app >> packet whose dst it doesn't know, and if it doesn't have a default >> route. > > Not in that way. > > Using the protocol as to be standardised, if an OLSR (v1 or v2) node > receives a packet from destination it doesn't know, it does nothing > to find that route. Maybe we have a misunderstanding. I meant that an OLSR router, when it receives a packet from a host permanently attached to that router, a packet that that OLSR router should forward, packet whose dst address that OLSR router doesn't know - the OLSR router should try to discover the route. It's not a packet that the app on that OLSR router receives, and whose dst that router doesn't know. > There is allowed to be responsiveness (a term we use as say > reactiveness would be confusing) in the protocol at the signalling > level. If an OLSR (v1 or v2) node receives a HELLO message containing > information about a neighbour it's never heard of, it doesn't have > to maintain its current fixed schedule to send a HELLO message > containing this extra information, but can do so early. This will > accelerate what you want here, and may even look reactive. But it's > more than just subtly different. A node that wants to find node X > can't make that happen, it has to wait for node X to inform it > (directly or, more usually, via other nodes). I think I understand that in the MANET network the route propagation can happen only with HELLOs advertised on link scope. I also understand that very frequent HELLOs may in the end look as routes are created immediately prior to an e2e application needing it. However, as the efficiency of MANET networks should be taken into account one deployer has to have the option of either rely on periodic advertisements or immediate requested responses. This is exactly as periodic RAs and RS/RA, or as periodic RIP advertisements and Triggered RIP. >> Similary, DYMO says it's on-demand but it should advertise RREP (or >> RREQs) periodically if it needs to maintain up to date information >> at all times. > > But maintaining up to date information about all destinations at all > times is not necessarily desirable. (Talk to 6LoWPAN people about > this, for example.) I agree not desirable. I wanted to mean that both tools should be in one spec (both the periodic advertisements _and_ the immediately-answered directed requests) and that deployers should be able to use whichever mechanism independently or tuned for ege 6LowPAN. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 06:53:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhWv-000367-Ha; Mon, 11 Jun 2007 06:53:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxhWu-0002yN-0F for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 06:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhWt-0002wa-MR for manet@ietf.org; Mon, 11 Jun 2007 06:53:47 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxhWs-00080Q-Ak for manet@ietf.org; Mon, 11 Jun 2007 06:53:47 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5BArjBV000050 for ; Mon, 11 Jun 2007 11:53:45 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5BArjK0016314 for ; Mon, 11 Jun 2007 11:53:45 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 11 Jun 2007 11:53:44 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 11:53:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: mobility physics and mathematics (was: manet] DYMOandother routing protocols) Date: Mon, 11 Jun 2007 11:53:44 +0100 Message-ID: In-Reply-To: <466D261A.8030409@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: mobility physics and mathematics (was: manet] DYMOandother routing protocols) Thread-Index: AcesFKbcl4JCPNIeStCTfY2nVMCaDwAARr9A From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 11 Jun 2007 10:53:44.0436 (UTC) FILETIME=[C7C7B340:01C7AC16] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Philippe Jacquet , manet@ietf.org, "Krishna Sankar \(ksankar\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I'm wondering whether NHDP should recommend the use=20 > Mobile IP when MANET nodes change their addresses (in addition to=20 > recommending sending new HELLO messages). I think that's out of the scope of NHDP, which is purely concerned not even with all of intra-MANET communications, but a subset of that. That sort of recommendation belongs in a higher level document, one which actually knows why addresses change and what the consequences are. NHDP is just responding to a change, it's not its job to suggest what else should be done. And maybe Mobile IP is the right answer, or maybe not in some circumstances, NHDP has no idea and building in a recommendation in NHDP would be inappropriate. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 07:02:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhfg-00025p-I4; Mon, 11 Jun 2007 07:02:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hxhfe-0001xw-8t for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 07:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhfd-0001xo-VX for manet@ietf.org; Mon, 11 Jun 2007 07:02:49 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxhfd-0001fB-JZ for manet@ietf.org; Mon, 11 Jun 2007 07:02:49 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5BB2i9Z027479 for ; Mon, 11 Jun 2007 12:02:45 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5BB2i0s023755 for ; Mon, 11 Jun 2007 12:02:44 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 11 Jun 2007 12:02:44 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 12:02:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Mon, 11 Jun 2007 12:02:44 +0100 Message-ID: In-Reply-To: <466D27FB.9000106@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DYMO and other routing protocols Thread-Index: AcesFcLqiJ/RJDD9QH2YXYQ3ov4f0gAARD5w From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 11 Jun 2007 11:02:44.0630 (UTC) FILETIME=[09C2C360:01C7AC18] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Philippe Jacquet , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I meant that an OLSR router, when it receives a packet from a host > permanently attached to that router, a packet that that OLSR router > should forward, packet whose dst address that OLSR router doesn't know - > the OLSR router should try to discover the route. No. That's a reactive approach. OLSR's approach is that destinations are established proactively. If you don't know the destination then either it's recently joined, and will make itself known soon, or it isn't available, there's no point trying to find it, it isn't there. If you get a packet with no destination, you should discard it. (Well, actually you could queue it, but that's outside OLSR and is an IP issue.) > I think I understand that in the MANET network the route propagation can > happen only with HELLOs advertised on link scope. No, you also need TC messages in OLSR. > I wanted to mean that both tools should be in one spec (both the > periodic advertisements _and_ the immediately-answered directed > requests) and that deployers should be able to use whichever mechanism > independently or tuned for ege 6LowPAN. That's not going to happen for the current protocols. OLSRv2 and DYMO should be completed this year. That's the WP chartered work. Producing a hybrid protocol is going back a step to experimental work. See for example Charlie Perkins recent post where he's interested in going forward with ideas in this area, but not to delay the current work. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 08:06:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxifO-00080E-NO; Mon, 11 Jun 2007 08:06:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxifM-0007zx-Qi for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 08:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxifM-0007zp-HD for manet@ietf.org; Mon, 11 Jun 2007 08:06:36 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxifM-000871-8N for manet@ietf.org; Mon, 11 Jun 2007 08:06:36 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1181563593!22007488!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11709 invoked from network); 11 Jun 2007 12:06:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 11 Jun 2007 12:06:33 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5BC6XW9010606; Mon, 11 Jun 2007 05:06:33 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5BC6W8a009655; Mon, 11 Jun 2007 07:06:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5BC6VM7009646; Mon, 11 Jun 2007 07:06:31 -0500 (CDT) Message-ID: <466D3AC0.9070802@gmail.com> Date: Mon, 11 Jun 2007 14:06:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] DYMO and other routing protocols References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-2, 09/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Philippe Jacquet , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> I meant that an OLSR router, when it receives a packet from a host >> permanently attached to that router, a packet that that OLSR >> router should forward, packet whose dst address that OLSR router >> doesn't know > - >> the OLSR router should try to discover the route. > > No. That's a reactive approach. OLSR's approach is that destinations > are established proactively. If you don't know the destination then > either it's recently joined, and will make itself known soon, or it > isn't available, there's no point trying to find it, it isn't there. > If you get a packet with no destination, you should discard it. > (Well, actually you could queue it, but that's outside OLSR and is an > IP issue.) > >> I think I understand that in the MANET network the route >> propagation > can >> happen only with HELLOs advertised on link scope. > > No, you also need TC messages in OLSR. YEs, right... Topology Control messages... >> I wanted to mean that both tools should be in one spec (both the >> periodic advertisements _and_ the immediately-answered directed >> requests) and that deployers should be able to use whichever >> mechanism independently or tuned for ege 6LowPAN. > > That's not going to happen for the current protocols. OLSRv2 and DYMO > should be completed this year. That's the WP chartered work. > Producing a hybrid protocol is going back a step to experimental > work. Please explain why do you think a joint protocol deserves it experimental status? On the contrary I think it can reflect consensus reaching and thus qualify for Standards Track, better than two separate protocols. No? > See for example Charlie Perkins recent post where he's interested in > going forward with ideas in this area, but not to delay the current > work. Yes, I've read it with interest. I agree with the point of not delaying agreed timelines. Remark though, as already posted on the list, the Charter has open the possiblity to converge: Charter: > Using mature components from previous work on experimental reactive and > proactive protocols, the WG will develop two Standards track routing > protocol specifications: > > - Reactive MANET Protocol (RMP) > - Proactive MANET Protocol (PMP) > > If significant commonality between RMRP and PMRP protocol modules is > observed, the WG may decide to go with a converged approach. I think that if we continue pushing two different protocols up to WG Last Call we implicitly agree that we have not found significant commonality between the two protocols. The Charter implies so. I personally think that two protocols right now is no different than three protocols a few years ago. Thus, experimental. Alex > > ******************************************************************** > 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 has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 08:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxiuH-0003Ms-9P; Mon, 11 Jun 2007 08:22:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxiuF-0003Mn-Tj for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 08:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxiuF-0003Mf-Eh for manet@ietf.org; Mon, 11 Jun 2007 08:21:59 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxiuE-000787-3p for manet@ietf.org; Mon, 11 Jun 2007 08:21:59 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1181564515!1311296!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6185 invoked from network); 11 Jun 2007 12:21:55 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 11 Jun 2007 12:21:55 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5BCLnRt014341; Mon, 11 Jun 2007 05:21:49 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l5BCLn5S017828; Mon, 11 Jun 2007 07:21:49 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5BCLl7Q017794; Mon, 11 Jun 2007 07:21:47 -0500 (CDT) Message-ID: <466D3E52.6060306@gmail.com> Date: Mon, 11 Jun 2007 14:21:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Re: mobility physics and mathematics (was: manet] DYMOandother routing protocols) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-2, 09/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Philippe Jacquet , manet@ietf.org, "Krishna Sankar \(ksankar\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> I'm wondering whether NHDP should recommend the use Mobile IP when >> MANET nodes change their addresses (in addition to recommending >> sending new HELLO messages). > > I think that's out of the scope of NHDP, which is purely concerned > not even with all of intra-MANET communications, but a subset of > that. That sort of recommendation belongs in a higher level document, > one which actually knows why addresses change and what the > consequences are. The consequences of a node changing its addresses affect _any_ protocol behaviour I believe... NHDP ignoring these consequences isn't quite ok IMHO. It is not sufficient for NHDP and OLSR to just state that when a node is changing its addresses it should re-advertise HELLOs. This will simply not work at least because of multicast joining. In MANET, route-advertised messages are multicasted to multicast groups. I believe this is the case for NHDP/OLSR's TC and HELLO. A MANET node wishing to receive these multicast messages should join the respective group (although the current OLSR/NHDP specs aren't yet recommending the join if I understand correctly). When a node joins a multicast group it offers its IP address. When that IP address changes the node is no longer receiving the multicast messages. With this in mind, I was thinking a possible suggestion is that either NHDP/OLSR specify that nodes don't change their addresses, or specify that if address change occurs (with AUTOCONF mechanism) then the multicast group effects and session interruption exist. Or similar... > NHDP is just responding to a change, it's not its job to suggest what > else should be done. And maybe Mobile IP is the right answer, or > maybe not in some circumstances, NHDP has no idea and building in a > recommendation in NHDP would be inappropriate. Ok... I think one main MANEMO effort is to look at what happens to a MANET protocol when the node changes its address. I think it won't work. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 12:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxmYP-0007ct-M0; Mon, 11 Jun 2007 12:15:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxmYO-0007cl-4E for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 12:15:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxmYN-0007cc-Qy for manet@ietf.org; Mon, 11 Jun 2007 12:15:39 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxmYM-0002AG-IX for manet@ietf.org; Mon, 11 Jun 2007 12:15:39 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5BGFZFG029612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2007 09:15:35 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5BGFZo2016204; Mon, 11 Jun 2007 09:15:35 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5BGFR8J015793; Mon, 11 Jun 2007 09:15:31 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:15:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: mobility physics and mathematics (was: manet]DYMOandother routing protocols) Date: Mon, 11 Jun 2007 09:15:30 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED867@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <466D3E52.6060306@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: mobility physics and mathematics (was: manet]DYMOandother routing protocols) Thread-Index: AcesIyQzCYFggJcYQv6EzbrFjFoLmAAHsJzQ References: <466D3E52.6060306@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" , "Dearlove, Christopher (UK)" X-OriginalArrivalTime: 11 Jun 2007 16:15:31.0155 (UTC) FILETIME=[BB7B3A30:01C7AC43] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Philippe Jacquet , manet@ietf.org, "Krishna Sankar \(ksankar\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > The consequences of a node changing its addresses affect=20 > _any_ protocol > behaviour I believe... Which addresses are you talking about? The ones assigned to MANET interfaces, or the ones assigned to other interfaces? The former may change while the latter remain stable, and applications would ordinarily use the latter. Fred fred.l.templin@boeing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 15:50:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptz-0001Pl-OV; Mon, 11 Jun 2007 15:50:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hxptr-0000zX-5H for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptq-0000vC-JL; Mon, 11 Jun 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptq-0007VX-Bp; Mon, 11 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5449C328F6; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00056m-7Z; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-iana-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group Author(s) : I. Chakeres Filename : draft-ietf-manet-iana-05.txt Pages : 6 Date : 2007-6-11 This document enumerates IANA allocations for use by MANET WG protocols. Specifically, a UDP port and two link-local multicast group addresses (IPv4 & IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-iana-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-iana-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11102841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11102841.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Mon Jun 11 16:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqUJ-0003LV-Gy; Mon, 11 Jun 2007 16:27:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxqUH-0003B9-Bz for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:27:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqU5-0002l2-DV for manet@ietf.org; Mon, 11 Jun 2007 16:27:29 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxqQC-0001M2-Eh for manet@ietf.org; Mon, 11 Jun 2007 16:23:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1181593407!29801931!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18610 invoked from network); 11 Jun 2007 20:23:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 11 Jun 2007 20:23:27 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5BKNRHx020555; Mon, 11 Jun 2007 13:23:27 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5BKNQEv029821; Mon, 11 Jun 2007 15:23:26 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.128]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5BKNMwY029783; Mon, 11 Jun 2007 15:23:23 -0500 (CDT) Message-ID: <466DAF39.1010608@gmail.com> Date: Mon, 11 Jun 2007 22:23:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: address change in MANET (was: [manet] Re: mobility physics and mathematics) References: <466D3E52.6060306@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED867@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED867@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-3, 11/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Dearlove, Christopher \(UK\)" , Philippe Jacquet , manet@ietf.org, "Krishna Sankar \(ksankar\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Templin, Fred L wrote: >> The consequences of a node changing its addresses affect _any_ >> protocol behaviour I believe... > > Which addresses are you talking about? The ones assigned to MANET > interfaces, or the ones assigned to other interfaces? The former may > change while the latter remain stable, and applications would > ordinarily use the latter. Not sure what you mean... you seem to say that some addresses may change without breaking anything in the MANET protocol, if I understand you correctly. I mean when an address assigned to a MANET interface is changing - this will break the MANET protocol itself (not only the apps), would you agree? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 22:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxvrt-0007Jz-H4; Mon, 11 Jun 2007 22:12:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hxvrr-0007Jr-Qy for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 22:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxvrr-0007Jj-H9 for manet@ietf.org; Mon, 11 Jun 2007 22:12:23 -0400 Received: from hub0.engr.sc.edu ([129.252.21.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxvrq-0004rq-A0 for manet@ietf.org; Mon, 11 Jun 2007 22:12:23 -0400 Received: from MAIL.engr.sc.edu ([129.252.21.21]) by HUB0.engr.sc.edu ([129.252.21.22]) with mapi; Mon, 11 Jun 2007 22:12:21 -0400 From: "NI, BIN" To: "manet@ietf.org" Date: Mon, 11 Jun 2007 22:11:21 -0400 Thread-Topic: one question about DSR in NS2 Thread-Index: AQHHrJccF3CUXkaqiE2Yyws6Us1/tA== Message-ID: <5CBBAC9E1EA66C4E976DDF1D1B55DFE616A4DAA920@MAIL.engr.sc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [manet] one question about DSR in NS2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi all: Sorry for bother. I am working on DSR in NS2 and have a problem. It seems that the packe= t is sent by Scheduler::instance().schedule(ll, p.pkt, 0.0) , which schedu= les the packet p.pkt to be send in 0.0 seconds to the link layer output. Now my problem is that after I made such a schedule, I want to cancel it= due to some condition change. So what can I do to cancel such schedule ? Any clue will be appreciated. Thanks very much! Bin Ni _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 23:25:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxx0e-0007qT-FN; Mon, 11 Jun 2007 23:25:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hxx0d-0007qO-4y for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 23:25:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxx0c-0007pm-QH for manet@ietf.org; Mon, 11 Jun 2007 23:25:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxwx4-0007zY-7s for manet@ietf.org; Mon, 11 Jun 2007 23:21:51 -0400 Received: by ug-out-1314.google.com with SMTP id j30so181196ugc for ; Mon, 11 Jun 2007 20:21:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=UdQuIu7SnPXY08LT9hZaOQE09IaA6HT7pKfM7E01vjVyVBFNzwHlcWfk64vnwbmbQ4gSRUc8q9HxcsNdkH1A5VNeHx7e/FbZ323aE/vwcRAeYT5wNNy+WcAwFEXC5gj+H9lgBpCmy+EUBdh4CiG8IJxVqAnB1CVBdb1E4D6A5wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=GfN5fkW9wkYRl4PhN4FYM09kgcKDnTUSA/b88G3ztIsVb/ShFfPcU5khQcAOGtZb8yX4o+brTEGAckXuJjvu8YDapy34W1szSowdXVMjag/MuyKzUjBlmDsh29haur6TEbmL8ZF+vwqvFw83XnLgVhlYl3iP8VrWDiFw8/f7xA0= Received: by 10.78.37.7 with SMTP id k7mr2484546huk.1181618509336; Mon, 11 Jun 2007 20:21:49 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 11 Jun 2007 20:21:49 -0700 (PDT) Message-ID: <374005f30706112021l411f3b2fgf45e464c11f785b6@mail.gmail.com> Date: Tue, 12 Jun 2007 08:51:49 +0530 From: "Ian Chakeres" To: "Ross Callon" , dward@cisco.com, iesg-secretary@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: manet Subject: [manet] Request to publish draft-ietf-manet-iana-05.txt - write-up included X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to request that draft-ietf-manet-iana-05.txt be published. I am the shepherding AD. Ian ===WRITE-UP=== 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? YES. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? YES the ID has been reviewed. NO there is no concern about the reviews. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? NO. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. NO. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? STRONG - Several other WG documents contain normative references to this ID. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. NO. 7. Have the chairs verified that the document adheres to all of the ID Checklist items ? YES. 8. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) YES. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard. 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document requests IANA allocate a UDP port and link-local multicast addresses (IPv4 & IPv6) for communication between MANET routers. * Working Group Summary Three WG protocols use link-local messaging for coordination among MANET routers. All these protocols will use the IANA allocations laid out in this document. There was discussion of whether site-local multicast addresses should be allocated. The WG decided to not allocate site-local multicast addresses at this time, because they are not required by the current WG documents. * Protocol Quality This document does not define a protocol. It specifies IANA allocations for other WG protocols. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 11 23:50:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxxPA-0002eZ-Ls; Mon, 11 Jun 2007 23:50:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HxxP8-0002eT-De for manet-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 23:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxxP8-0002eL-49 for manet@ietf.org; Mon, 11 Jun 2007 23:50:50 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxxP6-0006SX-O2 for manet@ietf.org; Mon, 11 Jun 2007 23:50:50 -0400 Received: by ug-out-1314.google.com with SMTP id j30so191018ugc for ; Mon, 11 Jun 2007 20:50:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t2nX44+/ooKsb2IbD+H7fDA37ko1wJtTA0nU0iTJDtf85rsWt4caWhQZe5AkWnTZri+iUVZc//SBxOhUh/hrz+eNZEVLgTnBJ6guI/swpwsOIwxzJPer7eKCX5op7fAQzzrSye6Jr/xPw9rFrr5J1kbYlh5OhyyVxU+iUnDQOes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DP2BF/pbYvpQX8ir4Husd1EOysyHzi6OpOABpIINYcyvZrQeou6qFFmbbWPOcDtubCausez4pR01/cKQ8KMqStuLNRKr5bd4zoDqS+XVFNC5i4LX0WVrkKOVjKMTxdhO4v4ZebJDJ/zyRrsDJqmMe4wWFHjJv9+isnMEJnmr6II= Received: by 10.78.142.14 with SMTP id p14mr2498945hud.1181620247609; Mon, 11 Jun 2007 20:50:47 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 11 Jun 2007 20:50:47 -0700 (PDT) Message-ID: <374005f30706112050t118d275br72bbed554368e136@mail.gmail.com> Date: Tue, 12 Jun 2007 09:20:47 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] DYMO and other routing protocols In-Reply-To: <466D3AC0.9070802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <466D3AC0.9070802@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Philippe Jacquet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Regarding the convergence within MANET, we have made significant progress in a converged approach. Here are some of the big examples of this fact - IANA, PacketBB, NHDP, and common TLVs. Regarding a merge between DYMO and OLSRv2, there is no straightforward way to merge distance vector and link state routing information. On a more positive note, I have indicated that I think it is possible to make DYMO/OLSRv2 more proactive/reactive. I agree with John Mullen that standardizing this advanced behavior should be done once we have standard protocols complete. Ian > Please explain why do you think a joint protocol deserves it > experimental status? On the contrary I think it can reflect consensus > reaching and thus qualify for Standards Track, better than two separate > protocols. No? > > Charter: > > Using mature components from previous work on experimental reactive and > > proactive protocols, the WG will develop two Standards track routing > > protocol specifications: > > > > - Reactive MANET Protocol (RMP) > > - Proactive MANET Protocol (PMP) > > > > If significant commonality between RMRP and PMRP protocol modules is > > observed, the WG may decide to go with a converged approach. > > I think that if we continue pushing two different protocols up to WG > Last Call we implicitly agree that we have not found significant > commonality between the two protocols. The Charter implies so. > > I personally think that two protocols right now is no different than > three protocols a few years ago. Thus, experimental. > > Alex _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 03:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0kR-0003K3-2K; Tue, 12 Jun 2007 03:25:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy0kP-0003I4-0Q for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 03:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0kO-0003HF-M0 for manet@ietf.org; Tue, 12 Jun 2007 03:25:00 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy0kN-0003rs-Ed for manet@ietf.org; Tue, 12 Jun 2007 03:25:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1181633098!22730946!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32598 invoked from network); 12 Jun 2007 07:24:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 12 Jun 2007 07:24:58 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5C7OpvL005461; Tue, 12 Jun 2007 00:24:52 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5C7Oo0W006717; Tue, 12 Jun 2007 02:24:50 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.120]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5C7OjnN006688; Tue, 12 Jun 2007 02:24:46 -0500 (CDT) Message-ID: <466E4A3D.2050706@gmail.com> Date: Tue, 12 Jun 2007 09:24:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] DYMO and other routing protocols References: <466D3AC0.9070802@gmail.com> <374005f30706112050t118d275br72bbed554368e136@mail.gmail.com> In-Reply-To: <374005f30706112050t118d275br72bbed554368e136@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-3, 11/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Philippe Jacquet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Regarding the convergence within MANET, we have made significant > progress in a converged approach. > > Here are some of the big examples of this fact - IANA, PacketBB, > NHDP, and common TLVs. Ok. > Regarding a merge between DYMO and OLSRv2, there is no > straightforward way to merge distance vector and link state routing > information. Indeed, sending routing information about immediate neighbors to all network members (link-state) is different than sending routing information to immediate neighbors about all network members (dv). For my clarification, isn't the IANA-reserved LL multicast address a link-local address? If both protocols send messages to this address then they both send to immediate neighbors then one can't be link-state... right? I'm afraid this ls-dv may be another entrenching classification. > On a more positive note, I have indicated that I think it is possible > to make DYMO/OLSRv2 more proactive/reactive. I agree with John > Mullen that standardizing this advanced behavior should be done once > we have standard protocols complete. Ok. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 05:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2Fg-0007Cr-UK; Tue, 12 Jun 2007 05:01:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy2Fg-0007Cl-71 for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 05:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2Ff-0007Cc-RQ; Tue, 12 Jun 2007 05:01:23 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy2Fe-0005NW-GA; Tue, 12 Jun 2007 05:01:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1181638881!22734329!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27260 invoked from network); 12 Jun 2007 09:01:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 12 Jun 2007 09:01:21 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5C91LoA000077; Tue, 12 Jun 2007 02:01:21 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5C91KWL018123; Tue, 12 Jun 2007 04:01:21 -0500 (CDT) Received: from [127.0.0.1] (ZFR01-2117.ea.mot.com [10.161.194.25]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5C91IPK018090; Tue, 12 Jun 2007 04:01:19 -0500 (CDT) Message-ID: <466E60DE.5000801@gmail.com> Date: Tue, 12 Jun 2007 11:01:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Request to publish draft-ietf-manet-iana-05.txt - write-up included References: <374005f30706112021l411f3b2fgf45e464c11f785b6@mail.gmail.com> In-Reply-To: <374005f30706112021l411f3b2fgf45e464c11f785b6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-3, 11/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Ross Callon , manet , iesg-secretary@ietf.org, dward@cisco.com X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > I would like to request that draft-ietf-manet-iana-05.txt be > published. I am the shepherding AD. SOrry... can one be a shepherding AD without being an AD? This is confusing to my mind... Thanks, Alex > Ian > > ===WRITE-UP=== > > 1. Have the chairs personally reviewed this version of the Internet > Draft (ID), and in particular, do they believe this ID is ready to > forward to the IESG for publication? > > YES. > > 2. Has the document had adequate review from both key WG members > and key non-WG members? Do you have any concerns about the depth or > breadth of the reviews that have been performed? > > YES the ID has been reviewed. NO there is no concern about the reviews. > > 3. Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? > > NO. > > 4. Do you have any specific concerns/issues with this document that > you believe the ADs and/or IESG should be aware of? For example, > perhaps you are uncomfortable with certain parts of the document, or > have concerns whether there really is a need for it. In any event, if > your issues have been discussed in the WG and the WG has indicated it > that it still wishes to advance the document, detail those concerns in > the write-up. > > NO. > > 5. How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > STRONG - Several other WG documents contain normative references to this > ID. > > 6. Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in separate > email to the Responsible Area Director. > > NO. > > 7. Have the chairs verified that the document adheres to all of the > ID Checklist items ? > > YES. > > 8. Is the document split into normative and informative references? > Are there normative references to IDs, where the IDs are not also > ready for advancement or are otherwise in an unclear state? (note here > that the RFC editor will not publish an RFC with normative references > to IDs, it will delay publication until all such IDs are also ready > for publication as RFCs.) > > YES. > > 9. What is the intended status of the document? (e.g., Proposed > Standard, Informational?) > > Proposed Standard. > > 10. For Standards Track and BCP documents, the IESG approval > announcement includes a write-up section with the following sections: > > * Technical Summary > > This document requests IANA allocate a UDP port and link-local > multicast addresses (IPv4 & IPv6) for communication between MANET > routers. > > * Working Group Summary > > Three WG protocols use link-local messaging for coordination among > MANET routers. All these protocols will use the IANA allocations laid > out in this document. There was discussion of whether site-local > multicast addresses should be allocated. The WG decided to not > allocate site-local multicast addresses at this time, because they are > not required by the current WG documents. > > * Protocol Quality > > This document does not define a protocol. It specifies IANA > allocations for other WG protocols. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 05:31:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2j7-0006Xt-7D; Tue, 12 Jun 2007 05:31:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy2j6-0006VP-9D for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 05:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2j5-0006TB-Ub; Tue, 12 Jun 2007 05:31:47 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy2j4-00035y-9P; Tue, 12 Jun 2007 05:31:47 -0400 Received: from [128.93.62.246] (dhcp-rocq-246.inria.fr [128.93.62.246]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5C9VivQ030296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 11:31:45 +0200 Message-ID: <466E6802.4020906@inria.fr> Date: Tue, 12 Jun 2007 11:31:46 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au> <4669398E.1030304@inria.fr> <4669A835.7090004@nokia.com> In-Reply-To: <4669A835.7090004@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-j-chkmail-Score: MSGID : 466E6800.003 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 466E6800.003 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l5C9VivQ030296 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: manet@ietf.org, manet-dt@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear Charlie, Sorry to have been kind of elliptic in my previous post. I didn't want=20 to mystify you;-) In proactive protocols, when a link fails the alternative route is=20 immediately available, because it is already stored in the database.=20 This what I call space diversity or space discrimination. The quantity=20 of information needed to this space diversity is controled by several=20 algorithms, the MPRs in OLSR is one example. This what I tried to name=20 space adaptability. In DYMO when a route fails, a new route is created with a new sequence=20 number. The two routes don't exist simultaneously and it takes time to=20 recover. This is what I tried to name time discremination. But I don't see time adaptability in DYMO. For example if a route=20 discovery fails it takes time to initiate a new route discovery. This=20 time should be controlled. Longer routes will have larger route=20 discovery delays, therefore need larger waiting time. However longer=20 route may have larger RREQ/RREP failure, therefore experience multiple=20 discovery route. In this case the waiting time should also be smaller in=20 order to minimize the delay to support multiple route discoveries.=20 Shorter waiting time may create broacast congestion and failure on other=20 routes which is a killing situation. Here, serious time adaptability is=20 missing. The exponential backoff won't help. The case with unidirectional links is a straightforward example. Assume=20 a node C with a strong transmission power and all other nodes with lower=20 power. Node C is on the path between a node A and a node B. Assume that=20 node C has, say, 10 unidirectional neighbors on that path toward B. The=20 first RREQ from A to B will go through C and via these neighbors and in=20 return the RREP will fail on one of these neighbors. The later will list=20 node C in its blacklist. After an initial waiting time, node A will=20 issue a new RREQ and the RREP will in return go via another=20 unidirectional neighor (since the first blacklisted link is denied):=20 therefore a second blacklisted link. And so forth until all=20 unidirectional links have been blacklisted one by one: 10 route=20 discoveries attempt. Applying binary exponential backoff, you will=20 experience a delay larger than 1,000 times the initial route discovery=20 interval time. If meanwhile one of the unidirectional neighbor un-blacklist its links=20 (this the only way to check if the link is now symmetric), then the=20 route discovery process may never end nor succeed. The blacklist period=20 (not specified in the draft) should be longer than the route discovery=20 delay. It seems that DYMO shows some fragility with respect to timers. I think=20 it would be good to specify at least some strong adaptability algorithms=20 to correct this. I don't think you need to pickup from proactive=20 protocols for this end. Below some links to real experiments where problems with recovery time=20 occurred. http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV http://www.seattlewireless.net/OpenWrt Charles E. Perkins a =E9crit : >=20 > Hello Philippe, >=20 > I really want to understand your point, but I confess > that I am somewhat mystified and not yet getting it. >=20 > How does OLSR adapt to "space"? Do you mean > Euclidean space with constant radio range? I can just > see the point about topology (because of MPRs), > but I think we should insist that both DYMO and > OLSR be equally able to utilize some SMF (or, lately for > us, SMURF) ways of flooding over reduced relay sets. >=20 > As I understand this, the common dependence on a > reduced relay set will give both proactive and reactive > approaches equal adaptability to topology. But this > still doesn't enlighten me about adaptability in space. >=20 > Regarding the adaptability in time... >=20 > DYMO has the following time-based dependencies > - route timeouts > - shifting route discovery anywhere up to and > including application launch > - some second order effects about sequence > numbers. > I can definitely see a role for a new extension which > enables nodes in a path to specify a non-default > value for the route timeout. But it is not clear to me > that this is what you are referring to. Could you be > a bit more explicit? >=20 > Anyway, this note is a long way of asking for more > details, and I hope you won't mind having a longer > discussion about it. >=20 > Finally, if you would care to point out cases where > DYMO performs poorly, but which are not able > to be explained by reliance on brute-force flooding, > it would be appreciated. I know about the case of > fully-connected traffic patterns, and a few other > corner cases, but somehow I feel you may have > something else in mind. >=20 > Regards, > Charlie P. >=20 >=20 > ext Philippe Jacquet wrote: >> I would say that from a very broad perspective, on-demand protocols=20 >> discriminate routes with respect to time and proactive protocols=20 >> discriminate routes with respect to space. Personnally I have=20 >> preference to proactive approach because it is richer and gives better= =20 >> internet legacy. Objectively the two approaches have their advantages=20 >> and drawbacks and the two should be considered. >> >> This said, I don't think that on-demand and proactive approaches are=20 >> represented at the same level in MANET. OLSRv2 has "space"=20 >> adaptability: i.e algorithms which automatically adapt to space and=20 >> topology variety, including for instance the MPR mechanism. In DYMO I=20 >> don't see an equivalent "time" adaptibility that goes beyond the=20 >> default values in timers. I think this may explain why the protocol=20 >> performs great in some scenario and very poorly in other. >> >> Some adaptability feature in DYMO would be welcome, not necessarily=20 >> proactive, but at least some memory based feature could help. >> >> Philippe >> >> David Murray a =E9crit : >>> Hi, >>> >>> I am wondering how DYMO fits in with the other routing protocols. I=20 >>> have read a number of papers that discuss how on-demand routing=20 >>> protocols like DSR/AODV work better in highly mobile environments=20 >>> where movement is fast, CPU and memory are low and batteries are=20 >>> limited. Equally, in situations where movement is very low, and there= =20 >>> are no power limitations, protocols like OLSR/TBRPF/STAR perform bett= er. >>> >>> So, I have a mental picture of OLSR/TBRPF being predominantly used in= =20 >>> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >>> users mobile devices ush as phones and PDAs. Is this correct or are=20 >>> things not quite as simple as this? (I know RFC 2501 discusses MANET=20 >>> applications and characteristics but the discussion is quite general) >>> >>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>> very similar situations (the ad hoc interconnect between users=20 >>> devices). I am aware that DYMO is a simplified version of AODV both=20 >>> in code and network operation. It seems like the major difference is=20 >>> the path accumulation feature in DYMO which allows nodes to append=20 >>> their information to a RREP to give other nodes better knowledge of=20 >>> the topology. It also seems that the hello feature has been removed=20 >>> in DYMO. So, is DYMO likely to be a replacement for AODV or do they=20 >>> have different uses/applications? >>> >>> Thanks for your time >>> >>> Dave >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 05:33:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2l6-0000A5-Ai; Tue, 12 Jun 2007 05:33:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy2l5-00009z-BW for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 05:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2l5-00009p-1v for manet@ietf.org; Tue, 12 Jun 2007 05:33:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy2l4-0003Tn-H8 for manet@ietf.org; Tue, 12 Jun 2007 05:33:51 -0400 Received: by ug-out-1314.google.com with SMTP id j30so286874ugc for ; Tue, 12 Jun 2007 02:33:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H22x6xnSlEk5v1Y8YzJkoXjX1QXqVj74gjX4KOG0Y8pkrvfssrNj2nC/swTQHznJXQGYQqksWWR5fpa/NNlR6IeYK0EVtGeESMMzLQ1SyYOe0xhd9xIY9oLPwvZK4zDU5GERyJZdiqwV3rsKKRkWOeesxqh6dJEjkwSes3YrKqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YnN5KSdRGfgW2bq5TCzphtaFB1q6oCuQg3rtw3us4oySsFzTmPcF1vDVxf34pM4RlUyjD0v9gG07nvg0/96RcoT9rtq/2RgoTgiROV8bFX5AD7xy/KtCaj6jd5f3uveif5xz5v6iKLIWhDgoqUsL2NHOYto67B5buVptfvxOrLs= Received: by 10.78.170.17 with SMTP id s17mr2584475hue.1181640829229; Tue, 12 Jun 2007 02:33:49 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Tue, 12 Jun 2007 02:33:49 -0700 (PDT) Message-ID: <374005f30706120233v4486824fqaecb226d57e19e10@mail.gmail.com> Date: Tue, 12 Jun 2007 15:03:49 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Request to publish draft-ietf-manet-iana-05.txt - write-up included In-Reply-To: <466E60DE.5000801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30706112021l411f3b2fgf45e464c11f785b6@mail.gmail.com> <466E60DE.5000801@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Ross Callon , manet , iesg-secretary@ietf.org, dward@cisco.com X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Whoops - typo, it should read - I am the shepherding WG chair. Ian On 6/12/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > I would like to request that draft-ietf-manet-iana-05.txt be > > published. I am the shepherding AD. > > SOrry... can one be a shepherding AD without being an AD? This is > confusing to my mind... > > Thanks, > > Alex > > > Ian > > > > ===WRITE-UP=== > > > > 1. Have the chairs personally reviewed this version of the Internet > > Draft (ID), and in particular, do they believe this ID is ready to > > forward to the IESG for publication? > > > > YES. > > > > 2. Has the document had adequate review from both key WG members > > and key non-WG members? Do you have any concerns about the depth or > > breadth of the reviews that have been performed? > > > > YES the ID has been reviewed. NO there is no concern about the reviews. > > > > 3. Do you have concerns that the document needs more review from a > > particular (broader) perspective (e.g., security, operational > > complexity, someone familiar with AAA, etc.)? > > > > NO. > > > > 4. Do you have any specific concerns/issues with this document that > > you believe the ADs and/or IESG should be aware of? For example, > > perhaps you are uncomfortable with certain parts of the document, or > > have concerns whether there really is a need for it. In any event, if > > your issues have been discussed in the WG and the WG has indicated it > > that it still wishes to advance the document, detail those concerns in > > the write-up. > > > > NO. > > > > 5. How solid is the WG consensus behind this document? Does it > > represent the strong concurrence of a few individuals, with others > > being silent, or does the WG as a whole understand and agree with it? > > > > STRONG - Several other WG documents contain normative references to this > > ID. > > > > 6. Has anyone threatened an appeal or otherwise indicated extreme > > discontent? If so, please summarize the areas of conflict in separate > > email to the Responsible Area Director. > > > > NO. > > > > 7. Have the chairs verified that the document adheres to all of the > > ID Checklist items ? > > > > YES. > > > > 8. Is the document split into normative and informative references? > > Are there normative references to IDs, where the IDs are not also > > ready for advancement or are otherwise in an unclear state? (note here > > that the RFC editor will not publish an RFC with normative references > > to IDs, it will delay publication until all such IDs are also ready > > for publication as RFCs.) > > > > YES. > > > > 9. What is the intended status of the document? (e.g., Proposed > > Standard, Informational?) > > > > Proposed Standard. > > > > 10. For Standards Track and BCP documents, the IESG approval > > announcement includes a write-up section with the following sections: > > > > * Technical Summary > > > > This document requests IANA allocate a UDP port and link-local > > multicast addresses (IPv4 & IPv6) for communication between MANET > > routers. > > > > * Working Group Summary > > > > Three WG protocols use link-local messaging for coordination among > > MANET routers. All these protocols will use the IANA allocations laid > > out in this document. There was discussion of whether site-local > > multicast addresses should be allocated. The WG decided to not > > allocate site-local multicast addresses at this time, because they are > > not required by the current WG documents. > > > > * Protocol Quality > > > > This document does not define a protocol. It specifies IANA > > allocations for other WG protocols. > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 05:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy32S-0006Qp-4H; Tue, 12 Jun 2007 05:51:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy32Q-0006Qe-Ua for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 05:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy32Q-0006QL-Kh for manet@ietf.org; Tue, 12 Jun 2007 05:51:46 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy32P-00070e-8O for manet@ietf.org; Tue, 12 Jun 2007 05:51:46 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5C9piJt008083 for ; Tue, 12 Jun 2007 10:51:44 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5C9piha001619 for ; Tue, 12 Jun 2007 10:51:44 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 12 Jun 2007 10:51:44 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 10:51:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 10:51:43 +0100 Message-ID: In-Reply-To: <466E4A3D.2050706@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DYMO and other routing protocols Thread-Index: AceswsuFpbVT75vMTxGWgEm2/UGH1QAE2mHA From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 12 Jun 2007 09:51:43.0888 (UTC) FILETIME=[4892E100:01C7ACD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > For my clarification, isn't the IANA-reserved LL multicast address a > link-local address?=20 Yes. > If both protocols send messages to this address > then they both send to immediate neighbors then one can't be > link-state... right? No. Take a simpler case, the most basic DV protocol. Each node sends messages listing all the nodes it knows about and the distance to each. It sends that to its immediate neighbours whenever it changes. It updates its distances when it gets such a message. Definitely distance vector, and definitely using sending to immediate neighbours (which could use a link local multicast address). (Also definitely not good enough once things change. But that's beside the current point.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 06:23:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy3X7-0003bE-99; Tue, 12 Jun 2007 06:23:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy3X4-0003aU-Cp for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 06:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy3X3-0003aA-Pj; Tue, 12 Jun 2007 06:23:25 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy3X1-0003Kt-8c; Tue, 12 Jun 2007 06:23:25 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.106]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hy3X0-0006ea-4V; Tue, 12 Jun 2007 06:23:22 -0400 X-MHO-User: U2FsdGVkX18D9SYChuHy8JBheN/fCo7D X-MHO-User: U2FsdGVkX1+eobCXF5vdraGv9FHfZCZJ X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+HuF5SQBggfdMP6NRsW+qq In-Reply-To: <7.0.0.16.2.20070331112019.040385c8@ie.niigata-u.ac.jp> References: <7.0.0.16.2.20070331112019.040385c8@ie.niigata-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Thomas Heide Clausen Date: Tue, 12 Jun 2007 12:23:17 +0200 To: mase X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: manet , manet-dt@ietf.org Subject: [manet] Re: [Manet-dt] Question and Comment on OLSRv2-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1968018490==" Errors-To: manet-bounces@ietf.org --===============1968018490== Content-Type: multipart/alternative; boundary=Apple-Mail-1--674348986 --Apple-Mail-1--674348986 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Kenichi, Thank you for your comments and apologies for the slightly belated reply. As I am sure you have noticed, we have reissued NHDP taking a lot of the comments provided by Owada-san, Satoh-san and others into account, and I think included also clarifications on the comments you have below. Regarding OLSRv2, we have been putting that a bit on a side, with the objective to get work done on packetbb and nhdp, which we want to get completed ASAP. Your comments on OLSRv2 are noted, and we will get back to you on those in short order. Thank you again for your comments and corrections, Thomas On 31Mar , 2007, at 6:33 AM, mase wrote: > Dear Thomas and all, > > I have some questions and comments on OLSRv2-03 and NHDP-02. > > 1. Local interface block in NHDP > The following description > "The first address block of the Local Interface Block MUST contain > the used address of the interface over which theHELLO message is > transmitted." was deleted in the -02 draft. > > Does this mean that the address must be included in the same order > in all copies of a given HELLO message, regardless of which OLSRv2 > nterface it is transmitted on? > > If so, the description in 9.2 of OLSRv2 -03 should be modified > because there is now no clear distinction in terms of the order of > addresses in the first address block between HELLO and TC messages. > > 2. Attached networks in OLSRv2 > > One of the main changes from -02 to -03 is "Local attached network > advertisement may be delegated to MPRs." > > To do this, information on local attached network of a node is > advertised in the Local Interface Block of the HELLO messages. > However, it is not clear which information base is poplulated when > this information is received by a MPR of this node. It is also not > clear how this information is carried by TC messages of the MPR. > Does the first address block or other address block of TC messages > carry this information? If the latter, It is also needed to modifiy > 13.1.3 of OLSRv2-03 since the gateway to the attached network is > not the MPR itself but the original node with the attaced network. > > Am I missing something? > > I also have a question with reagard to attached network > advertisement in HELLO messages. Why may attached networks with > dist>0 not be advertized in HELLO messages? > > > 3. "Local Attached Neighbor Tuple" in 12 of OLSRv2-03 should be > "Local Attached Nework Tuple". > > Thanks, > Kenichi > > > > > > > > > _______________________________________________ > Manet-dt mailing list > Manet-dt@ietf.org > https://www1.ietf.org/mailman/listinfo/manet-dt > -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ --Apple-Mail-1--674348986 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear Kenichi,

Thank you for your comments = and apologies for the slightly belated reply. As I am sure you have = noticed, we have reissued NHDP taking a lot of the comments provided by = Owada-san, Satoh-san and others into account, and I think included also = clarifications on the comments you have below.

Regarding OLSRv2, we have = been putting that a bit on a side, with the objective to get work done = on packetbb and nhdp, which we want to get completed ASAP. Your comments = on OLSRv2 are noted, and we will get back to you on those in short = order.

Thank = you again for your comments and corrections,

Thomas

On 31Mar , 2007, at 6:33 AM, mase wrote:

Dear = Thomas and all,

I have some questions and = comments on OLSRv2-03 and NHDP-02.

1. Local = interface block in NHDP
The following = description
"The first address block of the Local Interface = Block MUST contain the used address of the interface over which theHELLO = message is transmitted." was deleted in the -02 = draft.

Does this mean that the address must be = included in the same order in all copies of a given HELLO message, = regardless of which OLSRv2 nterface it is transmitted = on?

If so, the description in 9.2 of OLSRv2 -03 = should be modified because there is now no clear distinction in terms of = the order of addresses in the first address block between HELLO and TC = messages.

2. Attached networks in = OLSRv2

One of the main changes from -02 to -03 = is "Local attached network advertisement may be delegated to = MPRs."

To do this, information on local = attached network of a node is advertised in the Local=A0 Interface Block = of the HELLO messages. However, it is not clear which information base = is poplulated=A0 when this information is received by a MPR of this = node. It is also not clear how this information is carried by TC = messages of the MPR. Does the first address block or other address block = of TC messages carry this information? If the latter, It is also needed = to modifiy 13.1.3 of OLSRv2-03 since the gateway to the attached network = is not the MPR itself but the original node with the attaced = network.

Am I missing = something?

I also have a question with reagard = to attached network advertisement in HELLO messages. Why may attached = networks with dist>0 not be advertized in HELLO = messages?


3. "Local Attached = Neighbor Tuple" in 12 of OLSRv2-03 should be "Local Attached Nework = Tuple".

Thanks,
Kenichi

<= /DIV>




=A0<= BR = class=3D"khtml-block-placeholder">


_______________________________________________
Manet-dt = mailing list

=

Thomas.Clausen@polytechniq= ue.fr



=
= --Apple-Mail-1--674348986-- --===============1968018490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1968018490==-- From manet-bounces@ietf.org Tue Jun 12 07:43:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4mW-00083t-6O; Tue, 12 Jun 2007 07:43:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy4mV-00083n-6M for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 07:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4mU-00083f-TA for manet@ietf.org; Tue, 12 Jun 2007 07:43:26 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy4mU-00007q-M6 for manet@ietf.org; Tue, 12 Jun 2007 07:43:26 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1181648605!17207870!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26977 invoked from network); 12 Jun 2007 11:43:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 12 Jun 2007 11:43:26 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5CBhPjx007100; Tue, 12 Jun 2007 04:43:25 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5CBhO5O015634; Tue, 12 Jun 2007 06:43:25 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5CBhMb5015583; Tue, 12 Jun 2007 06:43:23 -0500 (CDT) Message-ID: <466E86D4.5050802@gmail.com> Date: Tue, 12 Jun 2007 13:43:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] DYMO and other routing protocols References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-3, 11/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> For my clarification, isn't the IANA-reserved LL multicast address a >> link-local address? > > Yes. > >> If both protocols send messages to this address >> then they both send to immediate neighbors then one can't be >> link-state... right? > > No. > > Take a simpler case, the most basic DV protocol. Each node > sends messages listing all the nodes it knows about and > the distance to each. It sends that to its immediate neighbours > whenever it changes. It updates its distances when it gets > such a message. Definitely distance vector, and definitely > using sending to immediate neighbours (which could use a > link local multicast address). Ok... but in this sense the LS protocol should send the info about its neighbors state to all routers in the MANET network (and not only to immediate neighbors) - right? Alex > > (Also definitely not good enough once things change. But > that's beside the current point.) > > ******************************************************************** > 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 has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 08:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5T5-00014F-Sn; Tue, 12 Jun 2007 08:27:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy5T4-00013c-9u for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 08:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5T3-00013E-Mb; Tue, 12 Jun 2007 08:27:25 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5Sx-0001fF-Ml; Tue, 12 Jun 2007 08:27:25 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5CCRIgA013763; Tue, 12 Jun 2007 13:27:18 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5CCRILS025041; Tue, 12 Jun 2007 13:27:18 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 12 Jun 2007 13:27:18 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 13:27:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 13:27:18 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Manet-dt] Question and Comment on OLSRv2-03 Thread-Index: Aces27rTWvLuDt8ETuiUFllRuxHdLAAAJ0Iw From: "Dearlove, Christopher \(UK\)" To: "Thomas Heide Clausen" , "mase" X-OriginalArrivalTime: 12 Jun 2007 12:27:18.0293 (UTC) FILETIME=[04500C50:01C7ACED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: manet , manet-dt@ietf.org Subject: [manet] RE: [Manet-dt] Question and Comment on OLSRv2-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org One key point here is that nhdp-03 is now, I think, technically essentially finished. However olsrv2-03 needs updating to be consistent with nhdp-03. Fortunately this won't be as big a job as the update to nhdp-03. Some specific comments. > Does this mean that the address must be included in the same > order in all copies of a given HELLO message, regardless of=20 > hich OLSRv2 nterface it is transmitted on? No. There's no constraint stated, so there is no constraint. You can put them in any order. And note that there are no different interface copies of a HELLO message, HELLO messages are generated independently on each interface, they aren't the same, and may not be sent at the same time either (but they may be, but are still different). > If so, the description in 9.2 of OLSRv2 -03 should be modified That's one of those things that needs checking. But TC messages are the same on all interfaces, including having the same ordering. Any ordering, but the same. > To do this, information on local attached network of a node is > advertised in the Local Interface Block of the HELLO messages. > However, it is not clear which information base is poplulated > when this information is received by a MPR of this node. I think it is explained. But when we're revising the document we'll bear that comment in mind, and check it. > I also have a question with reagard to attached network > advertisement in HELLO messages. Why may attached networks > with dist>0 not be advertized in HELLO messages? The main reason is that you can do this for free in a HELLO message without modifying NHDP in this case. (In fact arguably we now should just say "treat it as a local non-MANET interface and put it in the Local Interface Set rather than the Local Attached Network Set. That's something we're thinking about.) To do it for dist>0 in a HELLO message is more tricky, although it can be done it may be unnecessarily complicating. > 3. "Local Attached Neighbor Tuple" in 12 of OLSRv2-03 > should be "Local Attached Nework Tuple". Thanks. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 08:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5t4-00050e-Qd; Tue, 12 Jun 2007 08:54:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy5t2-0004q9-P6 for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 08:54:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5t2-0004mT-0s; Tue, 12 Jun 2007 08:54:16 -0400 Received: from server18.pronicsolutions.com ([66.103.131.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hy5sx-0005hf-Ru; Tue, 12 Jun 2007 08:54:15 -0400 Received: from [24.126.99.124] (helo=HerbRubens) by server18.pronicsolutions.com with esmtpa (Exim 4.66) (envelope-from ) id 1Hy5su-0002BH-PJ; Tue, 12 Jun 2007 08:54:09 -0400 From: "Herbert Rubens" To: "'Philippe Jacquet'" , "'Charles E. Perkins'" References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr> <4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 08:54:00 -0400 Organization: Persistent Systems, LLC Message-ID: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <466E6802.4020906@inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aces1IUiq90quPCQSZWpGIW5Ca84NQAGmQJg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server18.pronicsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - persistentsystems.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: manet@ietf.org, manet-dt@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hrubens@persistentsystems.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Philippe, Correct me if I am wrong, but Link-State protocols (e.g. OLSR) are generally not 'instantaneously loop free'. Meaning if a link metric = changes or a link goes from working to not working, the link-state database is = not loop free until an update is received by all of the nodes in the = network. Consider a simple example: if data is flowing along a path and a node = along the path decides that the next-hop link is no longer working. If it = removes the link from the data-base and re-computes the path, the route might be back to the node that sent it the packet. Until that node receives an = update you will have a loop in the network.=20 It appears that when a link fails on an active link-state path, you technically can't be routing reliably without a flood propagating the = entire network. In an on-demand (dymo, aodv, dsr) protocol, when a link fails = on an active path you also need to propagate a flood to the entire network = before the routing can continue. So while link-state protocols actively track = every imaginable path, it's not clear that they actually perform differently = in the link-failure case that you suggested.=20 -Herb -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 Sent: Tuesday, June 12, 2007 5:32 AM To: Charles E. Perkins Cc: manet@ietf.org; manet-dt@ietf.org Subject: Re: [manet] DYMO and other routing protocols Dear Charlie, Sorry to have been kind of elliptic in my previous post. I didn't want=20 to mystify you;-) In proactive protocols, when a link fails the alternative route is=20 immediately available, because it is already stored in the database.=20 This what I call space diversity or space discrimination. The quantity=20 of information needed to this space diversity is controled by several=20 algorithms, the MPRs in OLSR is one example. This what I tried to name=20 space adaptability. In DYMO when a route fails, a new route is created with a new sequence=20 number. The two routes don't exist simultaneously and it takes time to=20 recover. This is what I tried to name time discremination. But I don't see time adaptability in DYMO. For example if a route=20 discovery fails it takes time to initiate a new route discovery. This=20 time should be controlled. Longer routes will have larger route=20 discovery delays, therefore need larger waiting time. However longer=20 route may have larger RREQ/RREP failure, therefore experience multiple=20 discovery route. In this case the waiting time should also be smaller in = order to minimize the delay to support multiple route discoveries.=20 Shorter waiting time may create broacast congestion and failure on other = routes which is a killing situation. Here, serious time adaptability is=20 missing. The exponential backoff won't help. The case with unidirectional links is a straightforward example. Assume=20 a node C with a strong transmission power and all other nodes with lower = power. Node C is on the path between a node A and a node B. Assume that=20 node C has, say, 10 unidirectional neighbors on that path toward B. The=20 first RREQ from A to B will go through C and via these neighbors and in=20 return the RREP will fail on one of these neighbors. The later will list = node C in its blacklist. After an initial waiting time, node A will=20 issue a new RREQ and the RREP will in return go via another=20 unidirectional neighor (since the first blacklisted link is denied):=20 therefore a second blacklisted link. And so forth until all=20 unidirectional links have been blacklisted one by one: 10 route=20 discoveries attempt. Applying binary exponential backoff, you will=20 experience a delay larger than 1,000 times the initial route discovery=20 interval time. If meanwhile one of the unidirectional neighbor un-blacklist its links=20 (this the only way to check if the link is now symmetric), then the=20 route discovery process may never end nor succeed. The blacklist period=20 (not specified in the draft) should be longer than the route discovery=20 delay. It seems that DYMO shows some fragility with respect to timers. I think=20 it would be good to specify at least some strong adaptability algorithms = to correct this. I don't think you need to pickup from proactive=20 protocols for this end. Below some links to real experiments where problems with recovery time=20 occurred. http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV http://www.seattlewireless.net/OpenWrt Charles E. Perkins a =E9crit : >=20 > Hello Philippe, >=20 > I really want to understand your point, but I confess > that I am somewhat mystified and not yet getting it. >=20 > How does OLSR adapt to "space"? Do you mean > Euclidean space with constant radio range? I can just > see the point about topology (because of MPRs), > but I think we should insist that both DYMO and > OLSR be equally able to utilize some SMF (or, lately for > us, SMURF) ways of flooding over reduced relay sets. >=20 > As I understand this, the common dependence on a > reduced relay set will give both proactive and reactive > approaches equal adaptability to topology. But this > still doesn't enlighten me about adaptability in space. >=20 > Regarding the adaptability in time... >=20 > DYMO has the following time-based dependencies > - route timeouts > - shifting route discovery anywhere up to and > including application launch > - some second order effects about sequence > numbers. > I can definitely see a role for a new extension which > enables nodes in a path to specify a non-default > value for the route timeout. But it is not clear to me > that this is what you are referring to. Could you be > a bit more explicit? >=20 > Anyway, this note is a long way of asking for more > details, and I hope you won't mind having a longer > discussion about it. >=20 > Finally, if you would care to point out cases where > DYMO performs poorly, but which are not able > to be explained by reliance on brute-force flooding, > it would be appreciated. I know about the case of > fully-connected traffic patterns, and a few other > corner cases, but somehow I feel you may have > something else in mind. >=20 > Regards, > Charlie P. >=20 >=20 > ext Philippe Jacquet wrote: >> I would say that from a very broad perspective, on-demand protocols=20 >> discriminate routes with respect to time and proactive protocols=20 >> discriminate routes with respect to space. Personnally I have=20 >> preference to proactive approach because it is richer and gives = better=20 >> internet legacy. Objectively the two approaches have their advantages = >> and drawbacks and the two should be considered. >> >> This said, I don't think that on-demand and proactive approaches are=20 >> represented at the same level in MANET. OLSRv2 has "space"=20 >> adaptability: i.e algorithms which automatically adapt to space and=20 >> topology variety, including for instance the MPR mechanism. In DYMO I = >> don't see an equivalent "time" adaptibility that goes beyond the=20 >> default values in timers. I think this may explain why the protocol=20 >> performs great in some scenario and very poorly in other. >> >> Some adaptability feature in DYMO would be welcome, not necessarily=20 >> proactive, but at least some memory based feature could help. >> >> Philippe >> >> David Murray a =E9crit : >>> Hi, >>> >>> I am wondering how DYMO fits in with the other routing protocols. I=20 >>> have read a number of papers that discuss how on-demand routing=20 >>> protocols like DSR/AODV work better in highly mobile environments=20 >>> where movement is fast, CPU and memory are low and batteries are=20 >>> limited. Equally, in situations where movement is very low, and = there=20 >>> are no power limitations, protocols like OLSR/TBRPF/STAR perform = better. >>> >>> So, I have a mental picture of OLSR/TBRPF being predominantly used = in=20 >>> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >>> users mobile devices ush as phones and PDAs. Is this correct or are=20 >>> things not quite as simple as this? (I know RFC 2501 discusses MANET = >>> applications and characteristics but the discussion is quite = general) >>> >>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>> very similar situations (the ad hoc interconnect between users=20 >>> devices). I am aware that DYMO is a simplified version of AODV both=20 >>> in code and network operation. It seems like the major difference is = >>> the path accumulation feature in DYMO which allows nodes to append=20 >>> their information to a RREP to give other nodes better knowledge of=20 >>> the topology. It also seems that the hello feature has been removed=20 >>> in DYMO. So, is DYMO likely to be a replacement for AODV or do they=20 >>> have different uses/applications? >>> >>> Thanks for your time >>> >>> Dave >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 10:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Xw-00028F-3g; Tue, 12 Jun 2007 10:40:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy7Xu-00027x-4V for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 10:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Xt-00027o-R3; Tue, 12 Jun 2007 10:40:33 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7Xt-0002H6-G9; Tue, 12 Jun 2007 10:40:33 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l5CEeTf5017185; Tue, 12 Jun 2007 10:40:31 -0400 (EDT) Message-Id: <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007061210402806437 ; Tue, 12 Jun 2007 10:40:28 -0400 From: "Justin Dean" To: , Date: Tue, 12 Jun 2007 10:44:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aces1IUiq90quPCQSZWpGIW5Ca84NQAGmQJgAAM3KKA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: [manet] Expanded tlv type field for packetbb? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org There has been some discussion among the authors of packetbb on the merits of adding an optional extended TLV type field (as well as the comments charlie has posted to the list.) While attempting to write a metric TLV document based on packetbb, for use with MANET protocols, the issue of how to include/define multiple metric types without using up a lot of the TLV type space came up. By using an optional type sub field a generalized metric TLV document can be written to allow for multiple metric types, different sized value fields, differing value representations, and how the metrics are to be used. This can be done with the current TLV type field but I can easily envision 10s if not 100s of metric types in the future. With our current space there would be little room for official assignments. The benefits are not limited to an unfinished not yet released TLV metric document. A TLV type field could be assigned to a commercial or research entity which would then allow much more flexibility in defining TLVs by using the subtype field, without having to resort to using the experimental (and possibly conflicting) TLV type space in the current TLV type field. On the negative side TLVs which used the extend type field would be 8 bits longer per TLV. TLVs which are concerned with 8 bits per TLV would not be forced to use this subfield however and there would be no extra overhead involved. An extra semantics bit would be assigned as outlined below. This would make the specification slightly more complex and only 2 bits would be left for future use in the semantics field. (In my mind if we aren't using them they are going to waste and if we have a good use for them we should be using them) The proposed changes would comprise mostly of the following. In Section 5.3 change to: = ? <-new optional field ? ? ? ? In Section 5.3 change to: bit 5 (hassubtype): if cleared ('0'), then is not included in . If set ('1'), then is included in . bits 6-7: are RESERVED and MUST each be cleared ('0') to be in accordance with this version of the specification. In Section 5.3 add: is an 8 bit field, specifying the subtype of the TLV, specific to the TLV type and kind (i.e. packet, message, or address block TLV). tlv-subtype is a variable, defined to equal if present, or 0 otherwise. tlv-fulltype is a variable, defined by: * tlv-fulltype = 256 * + tlv-subtype; Section 5.3.2 change to: TLVs in the same TLV block MUST be sorted in ascending tlv-fulltype order. Two or more TLVs with the same tlv-fulltype associated with the same address block MUST NOT both cover any address. TLVs with the same tlv-fulltype associated with the same address block MUST be sorted in ascending index-start order. In Section 6.1 Table 5 add column Subtype. In existing row set to 0. Add new row for subtype 1-255 RESERVED. In Section 7 change to A new registry for packet TLV types must be created, with no initial assignments. Future values in the range 0-127 can be allocated using standards action [3]. Additionally, values in the range 128-255 are reserved for private/local use. If a TLV type is allocated a new registry for subtypes of that type must be created. A new registry for message TLV types must be created with no initial assignments. Future values in the range 0-127 can be allocated using standards action [3]. Additionally, values in the range 128-255 are reserved for private/local use. If a TLV type is allocated a new registry for subtypes of that type must be created. A new registry for address block TLV types must be created with initial assignments as specified in Table 7. Future values in the range 1-127 can be allocated using standards action [3]. Additionally, values in the range 128-255 are reserved for private/ local use. If a TLV type is allocated a new registry for subtypes of that type must be created. Justin Dean _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 11:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7tg-0008Cg-Jb; Tue, 12 Jun 2007 11:03:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy7te-0008BZ-SZ for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 11:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7te-0008BG-30; Tue, 12 Jun 2007 11:03:02 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7td-00084G-NB; Tue, 12 Jun 2007 11:03:02 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5CF2wtt017598; Tue, 12 Jun 2007 16:02:58 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5CF2w6M015969; Tue, 12 Jun 2007 16:02:58 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 12 Jun 2007 16:02:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 16:02:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Expanded tlv type field for packetbb? Date: Tue, 12 Jun 2007 16:02:57 +0100 Message-ID: In-Reply-To: <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Expanded tlv type field for packetbb? Thread-Index: Aces1IUiq90quPCQSZWpGIW5Ca84NQAGmQJgAAM3KKAAAQoHgA== From: "Dearlove, Christopher \(UK\)" To: "Justin Dean" , , X-OriginalArrivalTime: 12 Jun 2007 15:02:58.0061 (UTC) FILETIME=[C33F8BD0:01C7AD02] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > There has been some discussion among the authors of packetbb on the merits > of adding an optional extended TLV type field I judge modifications to packetbb (and other protocols here)on four main axes: - Extensibility - Simplicity - Efficiency - Timeliness On these four axes, this proposal is aimed at increasing extensibility, and Justin has a reasoned argument for it. I'm not completely sold on that we will need more TLVs than we can afford out of the general space (proprietary extensions can use the 128+ space) but neither can I be sure they won't be needed. This is a cost on the simplicity axis; not a lot in the ID (I wrote the changes Justin quotes - he's omitted a couple of details I found as not essential to this discussion) but some in code. This is a potential issue for those who are considering formal testing. On efficiency it's neutral, or actually arguably a gain as some possible alternatives if you do run out of TLV types are inefficient. But the key one to my mind is timeliness. packetbb is on the critical path of all the WG protocols, and it is not just due, but overdue, to get it to the IESG. If the consensus is "do this, just this, get it out" that's tolerable. If it opens the gates to people wanting all sorts of other things added/changed (apart, of course, from editorial matters - and we've also taken on board splitting message header options) then we as a WG (and the active packetbb authors in particular) really can't afford this. I'd rather go without this than introduce further such delay. (I - not uniquely, but unlike most people here - would also have to change my packetbb software. I haven't made this an issue above, but it is an issue for me, mostly about testing, even though mine isn't formal.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 11:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8RS-0008Bv-05; Tue, 12 Jun 2007 11:37:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy8RQ-0008AZ-AZ for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 11:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8RP-00088W-W3 for manet@ietf.org; Tue, 12 Jun 2007 11:37:56 -0400 Received: from exchange-fe2a.nmsu.edu ([128.123.34.179] helo=exchange-fe2.ACN.ad.nmsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8RO-0002hM-45 for manet@ietf.org; Tue, 12 Jun 2007 11:37:55 -0400 Received: from EXCHANGE-BE1.ACN.ad.nmsu.edu ([128.123.34.119]) by exchange-fe2.ACN.ad.nmsu.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 09:37:53 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 09:37:53 -0600 Message-ID: In-Reply-To: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [manet] DYMO and other routing protocols Thread-index: Aces1IUiq90quPCQSZWpGIW5Ca84NQAGmQJgAANT8CA= References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr><4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> From: "Mullen, John" To: X-OriginalArrivalTime: 12 Jun 2007 15:37:53.0112 (UTC) FILETIME=[A3FEF580:01C7AD07] X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Good points! If that were not enough, it is the nature of wireless communications = that any transmission attempt may fail on a "working" link or be = successful on a "non-working" one. Because there is always a finite = probability of success on all links, one cannot be entirely sure which = nodes actually get each updates, assuming they are sent UDP. If you use = ACKs, on the other hand, there is the problem of deciding which node(s) = decide when each update is complete and how that knowledge is made known = to the network.=20 I think this problem is manageable in a small, local net, but I'm not = aware of a solution that is scalable to a MANET containing routes of = four or more links. Between random variations in received signal = strength due to fading and shadowing, local interference, overflowing = buffers, and who knows what, the chances of every update reaching all = nodes in a geographically large MANET are very small. Thus, it would be = unlikely that all nodes would have the same image of the topology, = meaning their tables would be inconsistent with each other and at odds = with the real link states. For that reason, any proactive protocol needs = to acknowledge that each node's tables are estimates of the actual link = states and must be robust enough to deal with incomplete information. This is one reason I think a hybrid approach would be advisable. Nodes = in a one-, or maybe two-hop neighborhood could exchange link data = frequently, e.g., by Hello messages, and would have a good chance of = having locally consistent link state data. These tables could provide = stable data as a basis for long-haul routes, improving the chances of a = good route, and accomplish local repair. However, the overhead for = informing an entire large MANET would be considerable. Aside from the = larger number of links to update, because probability of end-to-end = success decreases with the number of hops, all other things being equal, = updates for distant nodes would have to be either ACKed or transmitted = multiple times in order to have the same assurance that link data is = correct globally as it would be locally. To illustrate. Suppose the probability of successful reception on a single hop is 0.98 = (Don't we wish!) and our standard is Pr(successful updates) >=3D 0.95. = Then,=20 # hops Pr(sucess in one try) minimum # tries for Pr(sucess) >=3D = 0.95 1 0.980 0.77 -> 1 2 0.960 0.93 -> 1 3 0.941 1.06 -> 2 4 0.922 1.17 -> 2 5 0.904 1.28 -> 2 =20 The actual degradation will depend on the actual probabilities, which = can be expected to differ by link and change over time, but the = principal will remain the same. More distant nodes will have a greater = chance of not receiving updates. To compensate, one would either have to = send multiple copies of the update or use ACKs. =20 Node density also plays a role. If a node has four one-hop neighbors and = the probability of success on each link is 0.98, the probability that = all four of its neighbors receiving a single UDP update is only 0.92. If = we modify the standard to require that the probability of all nodes = receiving the update be at least 0.95, now one needs two transmissions = of each update just to meet the standard in the one-hop neighborhood. = Going further not only increases the number of hops, but also the number = of nodes, so at some point, the overhead would become impractically = high. Additionally, sending multiple copies of an update or using ACKs = will increase the average time to propagate the updates, which will = increase the risk that the update itself is actually no longer valid. = And that is just to be 95% sure that all nodes have current data. There = is still a 5% chance that any random node will have invalid data.=20 The number of updates also affects the situation. Suppose there are ten = updates a minute, each containing only the changed information, not the = complete set of MANET link states, and the probability that each update = is successful is 0.95. The probability that all nodes will have correct = data from all ten of the changes that occurred in that one minute, after = enough time has passed to propagate the updates, is only about 0.6. Although the actual numbers may differ, there will always be some = probability of failure on an attempt on any link, so there will always = be a sizable chance that any random node will have incorrect link state = data. Reducing the maximum probability of invalid data increases the = difficulty of meeting that standard exponentially. Reducing it to zero = is impossible. Bottom line: To be successful in a wireless MANET, the routing protocol = needs to live with the fact that any tabled information may not be = current and have mechanisms to deal with that possibility. John P. Mullen, Ph.D. (505) 646-2958 jomullen@nmsu.edu =20 -----Original Message----- From: Herbert Rubens [mailto:hrubens@persistentsystems.com]=20 Sent: Tuesday, June 12, 2007 6:54 AM To: 'Philippe Jacquet'; 'Charles E. Perkins' Cc: manet@ietf.org; manet-dt@ietf.org Subject: RE: [manet] DYMO and other routing protocols Philippe, Correct me if I am wrong, but Link-State protocols (e.g. OLSR) are generally not 'instantaneously loop free'. Meaning if a link metric = changes or a link goes from working to not working, the link-state database is = not loop free until an update is received by all of the nodes in the = network. Consider a simple example: if data is flowing along a path and a node = along the path decides that the next-hop link is no longer working. If it = removes the link from the data-base and re-computes the path, the route might be back to the node that sent it the packet. Until that node receives an = update you will have a loop in the network.=20 It appears that when a link fails on an active link-state path, you technically can't be routing reliably without a flood propagating the = entire network. In an on-demand (dymo, aodv, dsr) protocol, when a link fails = on an active path you also need to propagate a flood to the entire network = before the routing can continue. So while link-state protocols actively track = every imaginable path, it's not clear that they actually perform differently = in the link-failure case that you suggested.=20 -Herb -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 Sent: Tuesday, June 12, 2007 5:32 AM To: Charles E. Perkins Cc: manet@ietf.org; manet-dt@ietf.org Subject: Re: [manet] DYMO and other routing protocols Dear Charlie, Sorry to have been kind of elliptic in my previous post. I didn't want=20 to mystify you;-) In proactive protocols, when a link fails the alternative route is=20 immediately available, because it is already stored in the database.=20 This what I call space diversity or space discrimination. The quantity=20 of information needed to this space diversity is controled by several=20 algorithms, the MPRs in OLSR is one example. This what I tried to name=20 space adaptability. In DYMO when a route fails, a new route is created with a new sequence=20 number. The two routes don't exist simultaneously and it takes time to=20 recover. This is what I tried to name time discremination. But I don't see time adaptability in DYMO. For example if a route=20 discovery fails it takes time to initiate a new route discovery. This=20 time should be controlled. Longer routes will have larger route=20 discovery delays, therefore need larger waiting time. However longer=20 route may have larger RREQ/RREP failure, therefore experience multiple=20 discovery route. In this case the waiting time should also be smaller in = order to minimize the delay to support multiple route discoveries.=20 Shorter waiting time may create broacast congestion and failure on other = routes which is a killing situation. Here, serious time adaptability is=20 missing. The exponential backoff won't help. The case with unidirectional links is a straightforward example. Assume=20 a node C with a strong transmission power and all other nodes with lower = power. Node C is on the path between a node A and a node B. Assume that=20 node C has, say, 10 unidirectional neighbors on that path toward B. The=20 first RREQ from A to B will go through C and via these neighbors and in=20 return the RREP will fail on one of these neighbors. The later will list = node C in its blacklist. After an initial waiting time, node A will=20 issue a new RREQ and the RREP will in return go via another=20 unidirectional neighor (since the first blacklisted link is denied):=20 therefore a second blacklisted link. And so forth until all=20 unidirectional links have been blacklisted one by one: 10 route=20 discoveries attempt. Applying binary exponential backoff, you will=20 experience a delay larger than 1,000 times the initial route discovery=20 interval time. If meanwhile one of the unidirectional neighbor un-blacklist its links=20 (this the only way to check if the link is now symmetric), then the=20 route discovery process may never end nor succeed. The blacklist period=20 (not specified in the draft) should be longer than the route discovery=20 delay. It seems that DYMO shows some fragility with respect to timers. I think=20 it would be good to specify at least some strong adaptability algorithms = to correct this. I don't think you need to pickup from proactive=20 protocols for this end. Below some links to real experiments where problems with recovery time=20 occurred. http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV http://www.seattlewireless.net/OpenWrt Charles E. Perkins a =E9crit : >=20 > Hello Philippe, >=20 > I really want to understand your point, but I confess > that I am somewhat mystified and not yet getting it. >=20 > How does OLSR adapt to "space"? Do you mean > Euclidean space with constant radio range? I can just > see the point about topology (because of MPRs), > but I think we should insist that both DYMO and > OLSR be equally able to utilize some SMF (or, lately for > us, SMURF) ways of flooding over reduced relay sets. >=20 > As I understand this, the common dependence on a > reduced relay set will give both proactive and reactive > approaches equal adaptability to topology. But this > still doesn't enlighten me about adaptability in space. >=20 > Regarding the adaptability in time... >=20 > DYMO has the following time-based dependencies > - route timeouts > - shifting route discovery anywhere up to and > including application launch > - some second order effects about sequence > numbers. > I can definitely see a role for a new extension which > enables nodes in a path to specify a non-default > value for the route timeout. But it is not clear to me > that this is what you are referring to. Could you be > a bit more explicit? >=20 > Anyway, this note is a long way of asking for more > details, and I hope you won't mind having a longer > discussion about it. >=20 > Finally, if you would care to point out cases where > DYMO performs poorly, but which are not able > to be explained by reliance on brute-force flooding, > it would be appreciated. I know about the case of > fully-connected traffic patterns, and a few other > corner cases, but somehow I feel you may have > something else in mind. >=20 > Regards, > Charlie P. >=20 >=20 > ext Philippe Jacquet wrote: >> I would say that from a very broad perspective, on-demand protocols=20 >> discriminate routes with respect to time and proactive protocols=20 >> discriminate routes with respect to space. Personnally I have=20 >> preference to proactive approach because it is richer and gives = better=20 >> internet legacy. Objectively the two approaches have their advantages = >> and drawbacks and the two should be considered. >> >> This said, I don't think that on-demand and proactive approaches are=20 >> represented at the same level in MANET. OLSRv2 has "space"=20 >> adaptability: i.e algorithms which automatically adapt to space and=20 >> topology variety, including for instance the MPR mechanism. In DYMO I = >> don't see an equivalent "time" adaptibility that goes beyond the=20 >> default values in timers. I think this may explain why the protocol=20 >> performs great in some scenario and very poorly in other. >> >> Some adaptability feature in DYMO would be welcome, not necessarily=20 >> proactive, but at least some memory based feature could help. >> >> Philippe >> >> David Murray a =E9crit : >>> Hi, >>> >>> I am wondering how DYMO fits in with the other routing protocols. I=20 >>> have read a number of papers that discuss how on-demand routing=20 >>> protocols like DSR/AODV work better in highly mobile environments=20 >>> where movement is fast, CPU and memory are low and batteries are=20 >>> limited. Equally, in situations where movement is very low, and = there=20 >>> are no power limitations, protocols like OLSR/TBRPF/STAR perform = better. >>> >>> So, I have a mental picture of OLSR/TBRPF being predominantly used = in=20 >>> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >>> users mobile devices ush as phones and PDAs. Is this correct or are=20 >>> things not quite as simple as this? (I know RFC 2501 discusses MANET = >>> applications and characteristics but the discussion is quite = general) >>> >>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>> very similar situations (the ad hoc interconnect between users=20 >>> devices). I am aware that DYMO is a simplified version of AODV both=20 >>> in code and network operation. It seems like the major difference is = >>> the path accumulation feature in DYMO which allows nodes to append=20 >>> their information to a RREP to give other nodes better knowledge of=20 >>> the topology. It also seems that the hello feature has been removed=20 >>> in DYMO. So, is DYMO likely to be a replacement for AODV or do they=20 >>> have different uses/applications? >>> >>> Thanks for your time >>> >>> Dave >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 12:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8nI-0003Ze-22; Tue, 12 Jun 2007 12:00:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy8my-0002wR-Hn for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 12:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8mx-0002tW-K1; Tue, 12 Jun 2007 12:00:11 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8mw-0007Jg-R3; Tue, 12 Jun 2007 12:00:11 -0400 Received: from [128.93.62.246] (dhcp-rocq-246.inria.fr [128.93.62.246]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5CG09ta024698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 18:00:10 +0200 Message-ID: <466EC30B.7080802@inria.fr> Date: Tue, 12 Jun 2007 18:00:11 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: hrubens@persistentsystems.com Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr> <4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> In-Reply-To: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 466EC309.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l5CG09ta024698 X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: manet@ietf.org, manet-dt@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Herb, In OLSR when a link fails, then the link change is immediately=20 advertized. The route change is therefore computed from the new=20 database: before the link advertizement packets are lost on the failing=20 link, and after they are routed on the new route. There is no loop. You may argue that some nodes may not receive the link change and send=20 the packet to an old relay and if the latter considers the former as=20 next hop in the new database in some pathological case, you may have a=20 temporary root. In practice it never happens (at least to my knowledge). On the other hand resolving routes with time interval as it is done with=20 on-demand protocols will actually avoid loop but with disconnection time=20 that can be long in practice. To my opinion this is something that would=20 need to be improved regarding practical implementation. Philippe Herbert Rubens a =E9crit : > Philippe, >=20 > Correct me if I am wrong, but Link-State protocols (e.g. OLSR) are > generally not 'instantaneously loop free'. Meaning if a link metric cha= nges > or a link goes from working to not working, the link-state database is = not > loop free until an update is received by all of the nodes in the networ= k. > Consider a simple example: if data is flowing along a path and a node a= long > the path decides that the next-hop link is no longer working. If it rem= oves > the link from the data-base and re-computes the path, the route might b= e > back to the node that sent it the packet. Until that node receives an u= pdate > you will have a loop in the network.=20 >=20 > It appears that when a link fails on an active link-state path, you > technically can't be routing reliably without a flood propagating the e= ntire > network. In an on-demand (dymo, aodv, dsr) protocol, when a link fails = on an > active path you also need to propagate a flood to the entire network be= fore > the routing can continue. So while link-state protocols actively track = every > imaginable path, it's not clear that they actually perform differently = in > the link-failure case that you suggested.=20 >=20 > -Herb >=20 > -----Original Message----- > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 > Sent: Tuesday, June 12, 2007 5:32 AM > To: Charles E. Perkins > Cc: manet@ietf.org; manet-dt@ietf.org > Subject: Re: [manet] DYMO and other routing protocols >=20 > Dear Charlie, >=20 > Sorry to have been kind of elliptic in my previous post. I didn't want=20 > to mystify you;-) >=20 > In proactive protocols, when a link fails the alternative route is=20 > immediately available, because it is already stored in the database.=20 > This what I call space diversity or space discrimination. The quantity=20 > of information needed to this space diversity is controled by several=20 > algorithms, the MPRs in OLSR is one example. This what I tried to name=20 > space adaptability. >=20 > In DYMO when a route fails, a new route is created with a new sequence=20 > number. The two routes don't exist simultaneously and it takes time to=20 > recover. This is what I tried to name time discremination. >=20 > But I don't see time adaptability in DYMO. For example if a route=20 > discovery fails it takes time to initiate a new route discovery. This=20 > time should be controlled. Longer routes will have larger route=20 > discovery delays, therefore need larger waiting time. However longer=20 > route may have larger RREQ/RREP failure, therefore experience multiple=20 > discovery route. In this case the waiting time should also be smaller i= n=20 > order to minimize the delay to support multiple route discoveries.=20 > Shorter waiting time may create broacast congestion and failure on othe= r=20 > routes which is a killing situation. Here, serious time adaptability is= =20 > missing. The exponential backoff won't help. >=20 > The case with unidirectional links is a straightforward example. Assume= =20 > a node C with a strong transmission power and all other nodes with lowe= r=20 > power. Node C is on the path between a node A and a node B. Assume that= =20 > node C has, say, 10 unidirectional neighbors on that path toward B. The= =20 > first RREQ from A to B will go through C and via these neighbors and in= =20 > return the RREP will fail on one of these neighbors. The later will lis= t=20 > node C in its blacklist. After an initial waiting time, node A will=20 > issue a new RREQ and the RREP will in return go via another=20 > unidirectional neighor (since the first blacklisted link is denied):=20 > therefore a second blacklisted link. And so forth until all=20 > unidirectional links have been blacklisted one by one: 10 route=20 > discoveries attempt. Applying binary exponential backoff, you will=20 > experience a delay larger than 1,000 times the initial route discovery=20 > interval time. >=20 > If meanwhile one of the unidirectional neighbor un-blacklist its links=20 > (this the only way to check if the link is now symmetric), then the=20 > route discovery process may never end nor succeed. The blacklist period= =20 > (not specified in the draft) should be longer than the route discovery=20 > delay. >=20 > It seems that DYMO shows some fragility with respect to timers. I think= =20 > it would be good to specify at least some strong adaptability algorithm= s=20 > to correct this. I don't think you need to pickup from proactive=20 > protocols for this end. >=20 > Below some links to real experiments where problems with recovery time=20 > occurred. >=20 >=20 > http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV > http://www.seattlewireless.net/OpenWrt >=20 >=20 >=20 > Charles E. Perkins a =E9crit : >> Hello Philippe, >> >> I really want to understand your point, but I confess >> that I am somewhat mystified and not yet getting it. >> >> How does OLSR adapt to "space"? Do you mean >> Euclidean space with constant radio range? I can just >> see the point about topology (because of MPRs), >> but I think we should insist that both DYMO and >> OLSR be equally able to utilize some SMF (or, lately for >> us, SMURF) ways of flooding over reduced relay sets. >> >> As I understand this, the common dependence on a >> reduced relay set will give both proactive and reactive >> approaches equal adaptability to topology. But this >> still doesn't enlighten me about adaptability in space. >> >> Regarding the adaptability in time... >> >> DYMO has the following time-based dependencies >> - route timeouts >> - shifting route discovery anywhere up to and >> including application launch >> - some second order effects about sequence >> numbers. >> I can definitely see a role for a new extension which >> enables nodes in a path to specify a non-default >> value for the route timeout. But it is not clear to me >> that this is what you are referring to. Could you be >> a bit more explicit? >> >> Anyway, this note is a long way of asking for more >> details, and I hope you won't mind having a longer >> discussion about it. >> >> Finally, if you would care to point out cases where >> DYMO performs poorly, but which are not able >> to be explained by reliance on brute-force flooding, >> it would be appreciated. I know about the case of >> fully-connected traffic patterns, and a few other >> corner cases, but somehow I feel you may have >> something else in mind. >> >> Regards, >> Charlie P. >> >> >> ext Philippe Jacquet wrote: >>> I would say that from a very broad perspective, on-demand protocols=20 >>> discriminate routes with respect to time and proactive protocols=20 >>> discriminate routes with respect to space. Personnally I have=20 >>> preference to proactive approach because it is richer and gives bette= r=20 >>> internet legacy. Objectively the two approaches have their advantages= =20 >>> and drawbacks and the two should be considered. >>> >>> This said, I don't think that on-demand and proactive approaches are=20 >>> represented at the same level in MANET. OLSRv2 has "space"=20 >>> adaptability: i.e algorithms which automatically adapt to space and=20 >>> topology variety, including for instance the MPR mechanism. In DYMO I= =20 >>> don't see an equivalent "time" adaptibility that goes beyond the=20 >>> default values in timers. I think this may explain why the protocol=20 >>> performs great in some scenario and very poorly in other. >>> >>> Some adaptability feature in DYMO would be welcome, not necessarily=20 >>> proactive, but at least some memory based feature could help. >>> >>> Philippe >>> >>> David Murray a =E9crit : >>>> Hi, >>>> >>>> I am wondering how DYMO fits in with the other routing protocols. I=20 >>>> have read a number of papers that discuss how on-demand routing=20 >>>> protocols like DSR/AODV work better in highly mobile environments=20 >>>> where movement is fast, CPU and memory are low and batteries are=20 >>>> limited. Equally, in situations where movement is very low, and ther= e=20 >>>> are no power limitations, protocols like OLSR/TBRPF/STAR perform bet= ter. >>>> >>>> So, I have a mental picture of OLSR/TBRPF being predominantly used i= n=20 >>>> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >>>> users mobile devices ush as phones and PDAs. Is this correct or are=20 >>>> things not quite as simple as this? (I know RFC 2501 discusses MANET= =20 >>>> applications and characteristics but the discussion is quite general= ) >>>> >>>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>>> very similar situations (the ad hoc interconnect between users=20 >>>> devices). I am aware that DYMO is a simplified version of AODV both=20 >>>> in code and network operation. It seems like the major difference is= =20 >>>> the path accumulation feature in DYMO which allows nodes to append=20 >>>> their information to a RREP to give other nodes better knowledge of=20 >>>> the topology. It also seems that the hello feature has been removed=20 >>>> in DYMO. So, is DYMO likely to be a replacement for AODV or do they=20 >>>> have different uses/applications? >>>> >>>> Thanks for your time >>>> >>>> Dave >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >> >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 12:55:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9e1-0003Sv-Lq; Tue, 12 Jun 2007 12:55:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy9dz-0003Sp-SO for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 12:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9dz-0003SW-3o; Tue, 12 Jun 2007 12:54:59 -0400 Received: from che.ojctech.com ([64.198.255.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9dx-0006xA-PD; Tue, 12 Jun 2007 12:54:59 -0400 Received: from che.ojctech.com (localhost [127.0.0.1]) by che.ojctech.com (8.12.8/8.12.8) with ESMTP id l5CGsvhH027672; Tue, 12 Jun 2007 11:54:57 -0500 Received: (from dyoung@localhost) by che.ojctech.com (8.12.8/8.12.8/Submit) id l5CGsvj5027670; Tue, 12 Jun 2007 11:54:57 -0500 Date: Tue, 12 Jun 2007 11:54:56 -0500 From: David Young To: manet@ietf.org, manet-dt@ietf.org Subject: Re: [manet] DYMO and other routing protocols Message-ID: <20070612165456.GE21417@che.ojctech.com> Mail-Followup-To: manet@ietf.org, manet-dt@ietf.org References: <4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Tue, Jun 12, 2007 at 08:54:00AM -0400, Herbert Rubens wrote: > It appears that when a link fails on an active link-state path, you > technically can't be routing reliably without a flood propagating the entire > network. As a practical matter, you do not ordinarily need to flood the entire network following a change of linkstate. You do need to flood the region a few hops in diameter where most loops occur. See for a discussion. Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 278-3933 ext 24 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 13:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9xa-0006L8-MR; Tue, 12 Jun 2007 13:15:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hy9xY-0006Ii-T4 for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 13:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9xY-0006IY-JR for manet@ietf.org; Tue, 12 Jun 2007 13:15:12 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9xW-00039a-Kl for manet@ietf.org; Tue, 12 Jun 2007 13:15:12 -0400 Received: from [192.168.0.5] (AVelizy-152-1-41-75.w82-120.abo.wanadoo.fr [82.120.244.75]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5CHF5pq008389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 19:15:06 +0200 Message-ID: <466ED498.6090102@inria.fr> Date: Tue, 12 Jun 2007 19:15:04 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "Mullen, John" Subject: Re: [manet] DYMO and other routing protocols References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr><4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 466ED499.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l5CHF5pq008389 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org You are right that the information about a local link will have an=20 increasing probability to be wrong when the distance increases. Not as=20 dramatic as you suggest (because the number of path for the TC to reach=20 a remote node also increases with distance and may correct the one path=20 failure probability). In this case a node database will give you a=20 "fisheye" view of the network: locally precise, more fuzzy at long=20 distance. The impact is not dramatic because the route starting from far=20 takes the good direction and details about the local wrong links are=20 resolved at the end. The path is thus very close to optimal. For this, you must activate the fisheye option, introduced by Gerla of=20 UCLA and included in OLSR long time ago. This allows to deal with large=20 network (with lot of hops and lot of nodes). The principle is that TCs=20 with large TTL are transmitted less frequently but with larger time to=20 live (otherwise remote nodes will timeout link set before a new TC=20 arrive). Other advantage: the control overhead is reduced and scales=20 better. This is included in the basic OLSRD codes and is used in practical=20 implementation. Philippe Mullen, John a =E9crit : > Good points! >=20 > If that were not enough, it is the nature of wireless communications th= at any transmission attempt may fail on a "working" link or be successful= on a "non-working" one. Because there is always a finite probability of = success on all links, one cannot be entirely sure which nodes actually ge= t each updates, assuming they are sent UDP. If you use ACKs, on the other= hand, there is the problem of deciding which node(s) decide when each up= date is complete and how that knowledge is made known to the network.=20 >=20 > I think this problem is manageable in a small, local net, but I'm not a= ware of a solution that is scalable to a MANET containing routes of four = or more links. Between random variations in received signal strength due = to fading and shadowing, local interference, overflowing buffers, and who= knows what, the chances of every update reaching all nodes in a geograph= ically large MANET are very small. Thus, it would be unlikely that all no= des would have the same image of the topology, meaning their tables would= be inconsistent with each other and at odds with the real link states. F= or that reason, any proactive protocol needs to acknowledge that each nod= e's tables are estimates of the actual link states and must be robust eno= ugh to deal with incomplete information. >=20 > This is one reason I think a hybrid approach would be advisable. Nodes = in a one-, or maybe two-hop neighborhood could exchange link data frequen= tly, e.g., by Hello messages, and would have a good chance of having loca= lly consistent link state data. These tables could provide stable data as= a basis for long-haul routes, improving the chances of a good route, and= accomplish local repair. However, the overhead for informing an entire l= arge MANET would be considerable. Aside from the larger number of links t= o update, because probability of end-to-end success decreases with the nu= mber of hops, all other things being equal, updates for distant nodes wou= ld have to be either ACKed or transmitted multiple times in order to have= the same assurance that link data is correct globally as it would be loc= ally. >=20 > To illustrate. >=20 > Suppose the probability of successful reception on a single hop is 0.98= (Don't we wish!) and our standard is Pr(successful updates) >=3D 0.95. T= hen,=20 >=20 > # hops Pr(sucess in one try) minimum # tries for Pr(sucess) >=3D= 0.95 >=20 > 1 0.980 0.77 -> 1 > 2 0.960 0.93 -> 1 > 3 0.941 1.06 -> 2 > 4 0.922 1.17 -> 2 > 5 0.904 1.28 -> 2 =20 >=20 > The actual degradation will depend on the actual probabilities, which c= an be expected to differ by link and change over time, but the principal = will remain the same. More distant nodes will have a greater chance of no= t receiving updates. To compensate, one would either have to send multipl= e copies of the update or use ACKs. =20 >=20 > Node density also plays a role. If a node has four one-hop neighbors an= d the probability of success on each link is 0.98, the probability that a= ll four of its neighbors receiving a single UDP update is only 0.92. If w= e modify the standard to require that the probability of all nodes receiv= ing the update be at least 0.95, now one needs two transmissions of each = update just to meet the standard in the one-hop neighborhood. Going furth= er not only increases the number of hops, but also the number of nodes, s= o at some point, the overhead would become impractically high. Additional= ly, sending multiple copies of an update or using ACKs will increase the = average time to propagate the updates, which will increase the risk that = the update itself is actually no longer valid. And that is just to be 95%= sure that all nodes have current data. There is still a 5% chance that a= ny random node will have invalid data.=20 >=20 > The number of updates also affects the situation. Suppose there are ten= updates a minute, each containing only the changed information, not the = complete set of MANET link states, and the probability that each update i= s successful is 0.95. The probability that all nodes will have correct da= ta from all ten of the changes that occurred in that one minute, after en= ough time has passed to propagate the updates, is only about 0.6. >=20 > Although the actual numbers may differ, there will always be some proba= bility of failure on an attempt on any link, so there will always be a si= zable chance that any random node will have incorrect link state data. Re= ducing the maximum probability of invalid data increases the difficulty o= f meeting that standard exponentially. Reducing it to zero is impossible. >=20 > Bottom line: To be successful in a wireless MANET, the routing protocol= needs to live with the fact that any tabled information may not be curre= nt and have mechanisms to deal with that possibility. >=20 > John P. Mullen, Ph.D. > (505) 646-2958 > jomullen@nmsu.edu > =20 > -----Original Message----- > From: Herbert Rubens [mailto:hrubens@persistentsystems.com]=20 > Sent: Tuesday, June 12, 2007 6:54 AM > To: 'Philippe Jacquet'; 'Charles E. Perkins' > Cc: manet@ietf.org; manet-dt@ietf.org > Subject: RE: [manet] DYMO and other routing protocols >=20 > Philippe, >=20 > Correct me if I am wrong, but Link-State protocols (e.g. OLSR) are > generally not 'instantaneously loop free'. Meaning if a link metric cha= nges > or a link goes from working to not working, the link-state database is = not > loop free until an update is received by all of the nodes in the networ= k. > Consider a simple example: if data is flowing along a path and a node a= long > the path decides that the next-hop link is no longer working. If it rem= oves > the link from the data-base and re-computes the path, the route might b= e > back to the node that sent it the packet. Until that node receives an u= pdate > you will have a loop in the network.=20 >=20 > It appears that when a link fails on an active link-state path, you > technically can't be routing reliably without a flood propagating the e= ntire > network. In an on-demand (dymo, aodv, dsr) protocol, when a link fails = on an > active path you also need to propagate a flood to the entire network be= fore > the routing can continue. So while link-state protocols actively track = every > imaginable path, it's not clear that they actually perform differently = in > the link-failure case that you suggested.=20 >=20 > -Herb >=20 > -----Original Message----- > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 > Sent: Tuesday, June 12, 2007 5:32 AM > To: Charles E. Perkins > Cc: manet@ietf.org; manet-dt@ietf.org > Subject: Re: [manet] DYMO and other routing protocols >=20 > Dear Charlie, >=20 > Sorry to have been kind of elliptic in my previous post. I didn't want=20 > to mystify you;-) >=20 > In proactive protocols, when a link fails the alternative route is=20 > immediately available, because it is already stored in the database.=20 > This what I call space diversity or space discrimination. The quantity=20 > of information needed to this space diversity is controled by several=20 > algorithms, the MPRs in OLSR is one example. This what I tried to name=20 > space adaptability. >=20 > In DYMO when a route fails, a new route is created with a new sequence=20 > number. The two routes don't exist simultaneously and it takes time to=20 > recover. This is what I tried to name time discremination. >=20 > But I don't see time adaptability in DYMO. For example if a route=20 > discovery fails it takes time to initiate a new route discovery. This=20 > time should be controlled. Longer routes will have larger route=20 > discovery delays, therefore need larger waiting time. However longer=20 > route may have larger RREQ/RREP failure, therefore experience multiple=20 > discovery route. In this case the waiting time should also be smaller i= n=20 > order to minimize the delay to support multiple route discoveries.=20 > Shorter waiting time may create broacast congestion and failure on othe= r=20 > routes which is a killing situation. Here, serious time adaptability is= =20 > missing. The exponential backoff won't help. >=20 > The case with unidirectional links is a straightforward example. Assume= =20 > a node C with a strong transmission power and all other nodes with lowe= r=20 > power. Node C is on the path between a node A and a node B. Assume that= =20 > node C has, say, 10 unidirectional neighbors on that path toward B. The= =20 > first RREQ from A to B will go through C and via these neighbors and in= =20 > return the RREP will fail on one of these neighbors. The later will lis= t=20 > node C in its blacklist. After an initial waiting time, node A will=20 > issue a new RREQ and the RREP will in return go via another=20 > unidirectional neighor (since the first blacklisted link is denied):=20 > therefore a second blacklisted link. And so forth until all=20 > unidirectional links have been blacklisted one by one: 10 route=20 > discoveries attempt. Applying binary exponential backoff, you will=20 > experience a delay larger than 1,000 times the initial route discovery=20 > interval time. >=20 > If meanwhile one of the unidirectional neighbor un-blacklist its links=20 > (this the only way to check if the link is now symmetric), then the=20 > route discovery process may never end nor succeed. The blacklist period= =20 > (not specified in the draft) should be longer than the route discovery=20 > delay. >=20 > It seems that DYMO shows some fragility with respect to timers. I think= =20 > it would be good to specify at least some strong adaptability algorithm= s=20 > to correct this. I don't think you need to pickup from proactive=20 > protocols for this end. >=20 > Below some links to real experiments where problems with recovery time=20 > occurred. >=20 >=20 > http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV > http://www.seattlewireless.net/OpenWrt >=20 >=20 >=20 > Charles E. Perkins a =E9crit : >> Hello Philippe, >> >> I really want to understand your point, but I confess >> that I am somewhat mystified and not yet getting it. >> >> How does OLSR adapt to "space"? Do you mean >> Euclidean space with constant radio range? I can just >> see the point about topology (because of MPRs), >> but I think we should insist that both DYMO and >> OLSR be equally able to utilize some SMF (or, lately for >> us, SMURF) ways of flooding over reduced relay sets. >> >> As I understand this, the common dependence on a >> reduced relay set will give both proactive and reactive >> approaches equal adaptability to topology. But this >> still doesn't enlighten me about adaptability in space. >> >> Regarding the adaptability in time... >> >> DYMO has the following time-based dependencies >> - route timeouts >> - shifting route discovery anywhere up to and >> including application launch >> - some second order effects about sequence >> numbers. >> I can definitely see a role for a new extension which >> enables nodes in a path to specify a non-default >> value for the route timeout. But it is not clear to me >> that this is what you are referring to. Could you be >> a bit more explicit? >> >> Anyway, this note is a long way of asking for more >> details, and I hope you won't mind having a longer >> discussion about it. >> >> Finally, if you would care to point out cases where >> DYMO performs poorly, but which are not able >> to be explained by reliance on brute-force flooding, >> it would be appreciated. I know about the case of >> fully-connected traffic patterns, and a few other >> corner cases, but somehow I feel you may have >> something else in mind. >> >> Regards, >> Charlie P. >> >> >> ext Philippe Jacquet wrote: >>> I would say that from a very broad perspective, on-demand protocols=20 >>> discriminate routes with respect to time and proactive protocols=20 >>> discriminate routes with respect to space. Personnally I have=20 >>> preference to proactive approach because it is richer and gives bette= r=20 >>> internet legacy. Objectively the two approaches have their advantages= =20 >>> and drawbacks and the two should be considered. >>> >>> This said, I don't think that on-demand and proactive approaches are=20 >>> represented at the same level in MANET. OLSRv2 has "space"=20 >>> adaptability: i.e algorithms which automatically adapt to space and=20 >>> topology variety, including for instance the MPR mechanism. In DYMO I= =20 >>> don't see an equivalent "time" adaptibility that goes beyond the=20 >>> default values in timers. I think this may explain why the protocol=20 >>> performs great in some scenario and very poorly in other. >>> >>> Some adaptability feature in DYMO would be welcome, not necessarily=20 >>> proactive, but at least some memory based feature could help. >>> >>> Philippe >>> >>> David Murray a =E9crit : >>>> Hi, >>>> >>>> I am wondering how DYMO fits in with the other routing protocols. I=20 >>>> have read a number of papers that discuss how on-demand routing=20 >>>> protocols like DSR/AODV work better in highly mobile environments=20 >>>> where movement is fast, CPU and memory are low and batteries are=20 >>>> limited. Equally, in situations where movement is very low, and ther= e=20 >>>> are no power limitations, protocols like OLSR/TBRPF/STAR perform bet= ter. >>>> >>>> So, I have a mental picture of OLSR/TBRPF being predominantly used i= n=20 >>>> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >>>> users mobile devices ush as phones and PDAs. Is this correct or are=20 >>>> things not quite as simple as this? (I know RFC 2501 discusses MANET= =20 >>>> applications and characteristics but the discussion is quite general= ) >>>> >>>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>>> very similar situations (the ad hoc interconnect between users=20 >>>> devices). I am aware that DYMO is a simplified version of AODV both=20 >>>> in code and network operation. It seems like the major difference is= =20 >>>> the path accumulation feature in DYMO which allows nodes to append=20 >>>> their information to a RREP to give other nodes better knowledge of=20 >>>> the topology. It also seems that the hello feature has been removed=20 >>>> in DYMO. So, is DYMO likely to be a replacement for AODV or do they=20 >>>> have different uses/applications? >>>> >>>> Thanks for your time >>>> >>>> Dave >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >> >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 14:31:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB8u-0008G1-Hf; Tue, 12 Jun 2007 14:31:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyB8t-0008Ft-0K for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 14:30:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB8s-0008Fl-Mo for manet@ietf.org; Tue, 12 Jun 2007 14:30:58 -0400 Received: from exchange-fe2a.nmsu.edu ([128.123.34.179] helo=exchange-fe2.ACN.ad.nmsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyB8r-0004Sm-MY for manet@ietf.org; Tue, 12 Jun 2007 14:30:58 -0400 Received: from EXCHANGE-BE1.ACN.ad.nmsu.edu ([128.123.34.119]) by exchange-fe2.ACN.ad.nmsu.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 12:30:56 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 12:30:54 -0600 Message-ID: In-Reply-To: <466ED498.6090102@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [manet] DYMO and other routing protocols Thread-index: AcetF57/wWWtmXwKQRiJ4cNmt5n3iQABf6xg References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr><4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <466ED498.6090102@inria.fr> From: "Mullen, John" To: X-OriginalArrivalTime: 12 Jun 2007 18:30:56.0143 (UTC) FILETIME=[D0C3C1F0:01C7AD1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Agreed Philippe, My computations were greatly simplified. However, there is always a = finite probability of error and it sounds like fisheye in OLSRD takes = this into account. However, this is my concern. I work with MANETs that support critical operations, e.g., military, = disaster relief, fire fighting, etc. In these applications, the node = distribution can be very uneven and quite dynamic, due to operational = needs. For example, firefighters will place themselves along the = perimeter of a forest fire and tend to work in uneven terrain. Hence, = routes are likely to have little redundancy and even a small amount of = movement could require a change, say if a node drops below a ridge. As = a result, an error is more likely to manifest itself. In addition, there = are people at risk and a loss of communications could have serious = consequences. My feeling is that an acceptable MANET routing protocol = needs to be robust enough that such errors do not cause an unnecessary = failure. In addition, it is possible that such nets will become = partitioned from time to time, so the protocol needs to be able to = rejoin partitioned nets quickly. I think this is harder if a global link = state approach is taken than if the long haul is reactive.=20 Bye for now, John P. Mullen, Ph.D. (505) 646-2958 jomullen@nmsu.edu =20 -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 Sent: Tuesday, June 12, 2007 11:15 AM To: Mullen, John Cc: manet@ietf.org Subject: Re: [manet] DYMO and other routing protocols You are right that the information about a local link will have an=20 increasing probability to be wrong when the distance increases. Not as=20 dramatic as you suggest (because the number of path for the TC to reach=20 a remote node also increases with distance and may correct the one path=20 failure probability). In this case a node database will give you a=20 "fisheye" view of the network: locally precise, more fuzzy at long=20 distance. The impact is not dramatic because the route starting from far = takes the good direction and details about the local wrong links are=20 resolved at the end. The path is thus very close to optimal. For this, you must activate the fisheye option, introduced by Gerla of=20 UCLA and included in OLSR long time ago. This allows to deal with large=20 network (with lot of hops and lot of nodes). The principle is that TCs=20 with large TTL are transmitted less frequently but with larger time to=20 live (otherwise remote nodes will timeout link set before a new TC=20 arrive). Other advantage: the control overhead is reduced and scales=20 better. This is included in the basic OLSRD codes and is used in practical=20 implementation. Philippe Mullen, John a =E9crit : > Good points! >=20 > If that were not enough, it is the nature of wireless communications = that any transmission attempt may fail on a "working" link or be = successful on a "non-working" one. Because there is always a finite = probability of success on all links, one cannot be entirely sure which = nodes actually get each updates, assuming they are sent UDP. If you use = ACKs, on the other hand, there is the problem of deciding which node(s) = decide when each update is complete and how that knowledge is made known = to the network.=20 >=20 > I think this problem is manageable in a small, local net, but I'm not = aware of a solution that is scalable to a MANET containing routes of = four or more links. Between random variations in received signal = strength due to fading and shadowing, local interference, overflowing = buffers, and who knows what, the chances of every update reaching all = nodes in a geographically large MANET are very small. Thus, it would be = unlikely that all nodes would have the same image of the topology, = meaning their tables would be inconsistent with each other and at odds = with the real link states. For that reason, any proactive protocol needs = to acknowledge that each node's tables are estimates of the actual link = states and must be robust enough to deal with incomplete information. >=20 > This is one reason I think a hybrid approach would be advisable. Nodes = in a one-, or maybe two-hop neighborhood could exchange link data = frequently, e.g., by Hello messages, and would have a good chance of = having locally consistent link state data. These tables could provide = stable data as a basis for long-haul routes, improving the chances of a = good route, and accomplish local repair. However, the overhead for = informing an entire large MANET would be considerable. Aside from the = larger number of links to update, because probability of end-to-end = success decreases with the number of hops, all other things being equal, = updates for distant nodes would have to be either ACKed or transmitted = multiple times in order to have the same assurance that link data is = correct globally as it would be locally. >=20 > To illustrate. >=20 > Suppose the probability of successful reception on a single hop is = 0.98 (Don't we wish!) and our standard is Pr(successful updates) >=3D = 0.95. Then,=20 >=20 > # hops Pr(sucess in one try) minimum # tries for Pr(sucess) = >=3D 0.95 >=20 > 1 0.980 0.77 -> 1 > 2 0.960 0.93 -> 1 > 3 0.941 1.06 -> 2 > 4 0.922 1.17 -> 2 > 5 0.904 1.28 -> 2 =20 >=20 > The actual degradation will depend on the actual probabilities, which = can be expected to differ by link and change over time, but the = principal will remain the same. More distant nodes will have a greater = chance of not receiving updates. To compensate, one would either have to = send multiple copies of the update or use ACKs. =20 >=20 > Node density also plays a role. If a node has four one-hop neighbors = and the probability of success on each link is 0.98, the probability = that all four of its neighbors receiving a single UDP update is only = 0.92. If we modify the standard to require that the probability of all = nodes receiving the update be at least 0.95, now one needs two = transmissions of each update just to meet the standard in the one-hop = neighborhood. Going further not only increases the number of hops, but = also the number of nodes, so at some point, the overhead would become = impractically high. Additionally, sending multiple copies of an update = or using ACKs will increase the average time to propagate the updates, = which will increase the risk that the update itself is actually no = longer valid. And that is just to be 95% sure that all nodes have = current data. There is still a 5% chance that any random node will have = invalid data.=20 >=20 > The number of updates also affects the situation. Suppose there are = ten updates a minute, each containing only the changed information, not = the complete set of MANET link states, and the probability that each = update is successful is 0.95. The probability that all nodes will have = correct data from all ten of the changes that occurred in that one = minute, after enough time has passed to propagate the updates, is only = about 0.6. >=20 > Although the actual numbers may differ, there will always be some = probability of failure on an attempt on any link, so there will always = be a sizable chance that any random node will have incorrect link state = data. Reducing the maximum probability of invalid data increases the = difficulty of meeting that standard exponentially. Reducing it to zero = is impossible. >=20 > Bottom line: To be successful in a wireless MANET, the routing = protocol needs to live with the fact that any tabled information may not = be current and have mechanisms to deal with that possibility. >=20 > John P. Mullen, Ph.D. > (505) 646-2958 > jomullen@nmsu.edu > =20 > -----Original Message----- > From: Herbert Rubens [mailto:hrubens@persistentsystems.com]=20 > Sent: Tuesday, June 12, 2007 6:54 AM > To: 'Philippe Jacquet'; 'Charles E. Perkins' > Cc: manet@ietf.org; manet-dt@ietf.org > Subject: RE: [manet] DYMO and other routing protocols >=20 > Philippe, >=20 > Correct me if I am wrong, but Link-State protocols (e.g. OLSR) are > generally not 'instantaneously loop free'. Meaning if a link metric = changes > or a link goes from working to not working, the link-state database is = not > loop free until an update is received by all of the nodes in the = network. > Consider a simple example: if data is flowing along a path and a node = along > the path decides that the next-hop link is no longer working. If it = removes > the link from the data-base and re-computes the path, the route might = be > back to the node that sent it the packet. Until that node receives an = update > you will have a loop in the network.=20 >=20 > It appears that when a link fails on an active link-state path, you > technically can't be routing reliably without a flood propagating the = entire > network. In an on-demand (dymo, aodv, dsr) protocol, when a link fails = on an > active path you also need to propagate a flood to the entire network = before > the routing can continue. So while link-state protocols actively track = every > imaginable path, it's not clear that they actually perform differently = in > the link-failure case that you suggested.=20 >=20 > -Herb >=20 > -----Original Message----- > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 > Sent: Tuesday, June 12, 2007 5:32 AM > To: Charles E. Perkins > Cc: manet@ietf.org; manet-dt@ietf.org > Subject: Re: [manet] DYMO and other routing protocols >=20 > Dear Charlie, >=20 > Sorry to have been kind of elliptic in my previous post. I didn't want = > to mystify you;-) >=20 > In proactive protocols, when a link fails the alternative route is=20 > immediately available, because it is already stored in the database.=20 > This what I call space diversity or space discrimination. The quantity = > of information needed to this space diversity is controled by several=20 > algorithms, the MPRs in OLSR is one example. This what I tried to name = > space adaptability. >=20 > In DYMO when a route fails, a new route is created with a new sequence = > number. The two routes don't exist simultaneously and it takes time to = > recover. This is what I tried to name time discremination. >=20 > But I don't see time adaptability in DYMO. For example if a route=20 > discovery fails it takes time to initiate a new route discovery. This=20 > time should be controlled. Longer routes will have larger route=20 > discovery delays, therefore need larger waiting time. However longer=20 > route may have larger RREQ/RREP failure, therefore experience multiple = > discovery route. In this case the waiting time should also be smaller = in=20 > order to minimize the delay to support multiple route discoveries.=20 > Shorter waiting time may create broacast congestion and failure on = other=20 > routes which is a killing situation. Here, serious time adaptability = is=20 > missing. The exponential backoff won't help. >=20 > The case with unidirectional links is a straightforward example. = Assume=20 > a node C with a strong transmission power and all other nodes with = lower=20 > power. Node C is on the path between a node A and a node B. Assume = that=20 > node C has, say, 10 unidirectional neighbors on that path toward B. = The=20 > first RREQ from A to B will go through C and via these neighbors and = in=20 > return the RREP will fail on one of these neighbors. The later will = list=20 > node C in its blacklist. After an initial waiting time, node A will=20 > issue a new RREQ and the RREP will in return go via another=20 > unidirectional neighor (since the first blacklisted link is denied):=20 > therefore a second blacklisted link. And so forth until all=20 > unidirectional links have been blacklisted one by one: 10 route=20 > discoveries attempt. Applying binary exponential backoff, you will=20 > experience a delay larger than 1,000 times the initial route discovery = > interval time. >=20 > If meanwhile one of the unidirectional neighbor un-blacklist its links = > (this the only way to check if the link is now symmetric), then the=20 > route discovery process may never end nor succeed. The blacklist = period=20 > (not specified in the draft) should be longer than the route discovery = > delay. >=20 > It seems that DYMO shows some fragility with respect to timers. I = think=20 > it would be good to specify at least some strong adaptability = algorithms=20 > to correct this. I don't think you need to pickup from proactive=20 > protocols for this end. >=20 > Below some links to real experiments where problems with recovery time = > occurred. >=20 >=20 > http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV > http://www.seattlewireless.net/OpenWrt >=20 >=20 >=20 > Charles E. Perkins a =E9crit : >> Hello Philippe, >> >> I really want to understand your point, but I confess >> that I am somewhat mystified and not yet getting it. >> >> How does OLSR adapt to "space"? Do you mean >> Euclidean space with constant radio range? I can just >> see the point about topology (because of MPRs), >> but I think we should insist that both DYMO and >> OLSR be equally able to utilize some SMF (or, lately for >> us, SMURF) ways of flooding over reduced relay sets. >> >> As I understand this, the common dependence on a >> reduced relay set will give both proactive and reactive >> approaches equal adaptability to topology. But this >> still doesn't enlighten me about adaptability in space. >> >> Regarding the adaptability in time... >> >> DYMO has the following time-based dependencies >> - route timeouts >> - shifting route discovery anywhere up to and >> including application launch >> - some second order effects about sequence >> numbers. >> I can definitely see a role for a new extension which >> enables nodes in a path to specify a non-default >> value for the route timeout. But it is not clear to me >> that this is what you are referring to. Could you be >> a bit more explicit? >> >> Anyway, this note is a long way of asking for more >> details, and I hope you won't mind having a longer >> discussion about it. >> >> Finally, if you would care to point out cases where >> DYMO performs poorly, but which are not able >> to be explained by reliance on brute-force flooding, >> it would be appreciated. I know about the case of >> fully-connected traffic patterns, and a few other >> corner cases, but somehow I feel you may have >> something else in mind. >> >> Regards, >> Charlie P. >> >> >> ext Philippe Jacquet wrote: >>> I would say that from a very broad perspective, on-demand protocols=20 >>> discriminate routes with respect to time and proactive protocols=20 >>> discriminate routes with respect to space. Personnally I have=20 >>> preference to proactive approach because it is richer and gives = better=20 >>> internet legacy. Objectively the two approaches have their = advantages=20 >>> and drawbacks and the two should be considered. >>> >>> This said, I don't think that on-demand and proactive approaches are = >>> represented at the same level in MANET. OLSRv2 has "space"=20 >>> adaptability: i.e algorithms which automatically adapt to space and=20 >>> topology variety, including for instance the MPR mechanism. In DYMO = I=20 >>> don't see an equivalent "time" adaptibility that goes beyond the=20 >>> default values in timers. I think this may explain why the protocol=20 >>> performs great in some scenario and very poorly in other. >>> >>> Some adaptability feature in DYMO would be welcome, not necessarily=20 >>> proactive, but at least some memory based feature could help. >>> >>> Philippe >>> >>> David Murray a =E9crit : >>>> Hi, >>>> >>>> I am wondering how DYMO fits in with the other routing protocols. I = >>>> have read a number of papers that discuss how on-demand routing=20 >>>> protocols like DSR/AODV work better in highly mobile environments=20 >>>> where movement is fast, CPU and memory are low and batteries are=20 >>>> limited. Equally, in situations where movement is very low, and = there=20 >>>> are no power limitations, protocols like OLSR/TBRPF/STAR perform = better. >>>> >>>> So, I have a mental picture of OLSR/TBRPF being predominantly used = in=20 >>>> stationary 802.11 mesh devices and AODV/DYMO being used to connect=20 >>>> users mobile devices ush as phones and PDAs. Is this correct or are = >>>> things not quite as simple as this? (I know RFC 2501 discusses = MANET=20 >>>> applications and characteristics but the discussion is quite = general) >>>> >>>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>>> very similar situations (the ad hoc interconnect between users=20 >>>> devices). I am aware that DYMO is a simplified version of AODV both = >>>> in code and network operation. It seems like the major difference = is=20 >>>> the path accumulation feature in DYMO which allows nodes to append=20 >>>> their information to a RREP to give other nodes better knowledge of = >>>> the topology. It also seems that the hello feature has been removed = >>>> in DYMO. So, is DYMO likely to be a replacement for AODV or do they = >>>> have different uses/applications? >>>> >>>> Thanks for your time >>>> >>>> Dave >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >> >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 15:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBgf-0005jN-Rv; Tue, 12 Jun 2007 15:05:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyBgd-0005g0-Ud for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 15:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBgd-0005fs-L7 for manet@ietf.org; Tue, 12 Jun 2007 15:05:51 -0400 Received: from mx4.iit.cnr.it ([146.48.98.151] helo=smtp.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyBgc-0003vq-5q for manet@ietf.org; Tue, 12 Jun 2007 15:05:51 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 9395612F0ED for ; Tue, 12 Jun 2007 21:05:45 +0200 (CEST) Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13313-07 for ; Tue, 12 Jun 2007 21:05:44 +0200 (CEST) X-SMTP-Auth: no Received: from mx4.iit.cnr.it (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 5FBE812F0FA for ; Tue, 12 Jun 2007 21:05:44 +0200 (CEST) Received: from Unknown (HELO webmail.iit.cnr.it) (192.168.1.4) by mx4.iit.cnr.it (qpsmtpd/0.32) with ESMTP; mar, 12 giu 2007 21:05:44 +0200 Received: from 196.28.49.2 (SquirrelMail authenticated user andrea.passarella@iit.cnr.it) by webmail.iit.cnr.it with HTTP; Tue, 12 Jun 2007 21:05:47 +0200 (CEST) Message-ID: <49377.196.28.49.2.1181675147.squirrel@webmail.iit.cnr.it> Date: Tue, 12 Jun 2007 21:05:47 +0200 (CEST) From: "Andrea Passarella" To: manet@ietf.org User-Agent: SquirrelMail/1.4.7-4.fc4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [manet] [IEEE MASS 2007]: Call for Demos X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: a.passarella@iit.cnr.it List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [ Apologies for possible duplicates] -------------------------------------------------- CALL FOR DEMOS Fourth International Conference on Mobile Ad hoc and Sensor Systems IEEE MASS 2007 http://cnd.iit.cnr.it/mass07 Sponsored by IEEE, IEEE Computer Society Oct. 8-11 Pisa, Italy Real experimentation has proven to be a fundamental methodology to evaluate mobile ad hoc and sensor systems. Furthermore, early prototyping is an outstanding way to understand real user requirements and help adoption of wireless ad hoc technologies by the mass market. In this view, IEEE MASS solicits demonstrations of mobile ad hoc and sensor systems showing real-systems prototypes at work, thus stimulating discussions among the attendees. Demonstrations from both academia and industry are welcome at most. ********************* HIGHLIGHTS ******************************* * * - Authors of all accepted demos will be invited to provide a * SHORT DEMO PAPER (3 pages) describing the demo features. * Short demo papers will be included in the MASS proceedings. * * - MASS 2007 will grant a "Best Demo Award" based upon both the * technical and innovation contribution. * **************************************************************** Demo proposals must be limited to 3 pages (IEEE conference template, font size no less than 10pt), describing the demo research framework, and what will be shown during the MASS demo session. The proposal must also include all the technical requirements for the demo. Demo proposals must be submitted as a SINGLE PDF FILE via e-mail to the demo chairs (mass07demo@iit.cnr.it). For more information, please refer to the demo section of the IEEE MASS 2007 official web site (http://cnd.iit.cnr.it/mass07). Topics of interest include, but are not limited to: * Provisioning of wireless QoS in terms of bandwidth and delay assurance * Routing protocols (unicast, multicast, broadcast, geocast) and metrics * Data transport in wireless ad hoc and sensor networks * Power-aware and energy-efficient design * Topology construction and coverage maintenance * Cross layer design and optimization * Incentives and game theoretic approaches in wireless ad-hoc networks * Localization and synchronization in wireless sensor networks * Data gathering, fusion, and dissemination in wireless sensor networks * Operating system and middleware support * Mesh networking * Delay tolerant networks and opportunistic networking * Handoff, mobility management and seamless internetworking * Peer-to-peer, overlay, and content distribution wireless ad hoc networks * Reliability, security, and trustworthiness issues in ad hoc and sensor networks Important Dates: Submission deadline: July 2, 2007 Acceptance notification: July 16, 2007 Camera-ready deadline: August 1, 2007 Conference date: October 8-11, 2007 Andrea Passarella and Gergely Zaruba IEEE MASS 2007 Demo Chairs _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 16:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCn5-0004Xw-Ki; Tue, 12 Jun 2007 16:16:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyCn3-0004XT-9O for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 16:16:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCn2-0004X8-Is; Tue, 12 Jun 2007 16:16:32 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCn1-0001E5-97; Tue, 12 Jun 2007 16:16:32 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l5CKGUAx007150; Tue, 12 Jun 2007 16:16:30 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007061216163008267 ; Tue, 12 Jun 2007 16:16:30 -0400 From: "Joe Macker" To: "'David Young'" , , References: <4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr><00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <20070612165456.GE21417@che.ojctech.com> Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 16:16:27 -0400 Message-ID: <005901c7ad2e$8ed31ed0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070612165456.GE21417@che.ojctech.com> Thread-Index: AcetEpEspMwVuc3MSBa6qXeOXmQTKwAGZ5UA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Right, an early paper 2001 Mobihoc by the same authors introduced a general class term called fuzzy sighted link state(FSLS). For experimentation we built a version of this into an early OLSR implementation at NRL. http://cs.itd.nrl.navy.mil/pubs/docs/ls_scaling_milcom03.pdf In the previous paper, we were able to use an OLSR implementation to compare fuzzy-sighted link state (FSLS), FSLS+MPR, MPR, and classical flooding for LS flooding. This analysis only did overhead scaling comparison, but it demonstrated some of the tradeoffs with density and diameter taken into account the design from the initial paper in combination with a working MANET protocol. As Phillile mentions others have done fisheye work as well. You do require longer term global state flooding so for long period fragmentations/changes there are some resynch/delay issues since less localized entries state will time out eventually. However such changes may trigger more reactive route learning as a possible solution. -Joe >-----Original Message----- >From: David Young [mailto:dyoung@pobox.com] >Sent: Tuesday, June 12, 2007 12:55 PM >To: manet@ietf.org; manet-dt@ietf.org >Subject: Re: [manet] DYMO and other routing protocols > >On Tue, Jun 12, 2007 at 08:54:00AM -0400, Herbert Rubens wrote: >> It appears that when a link fails on an active >link-state path, you >> technically can't be routing reliably without a flood >propagating the >> entire network. > >As a practical matter, you do not ordinarily need to flood the >entire network following a change of linkstate. You do need >to flood the region a few hops in diameter where most loops >occur. See > for a >discussion. > >Dave > >-- >David Young OJC Technologies >dyoung@ojctech.com Urbana, IL * (217) 278-3933 ext 24 > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 16:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCyY-0005WO-Aa; Tue, 12 Jun 2007 16:28:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyCyW-0005TN-6y for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 16:28:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCRT-0004AW-JE for manet@ietf.org; Tue, 12 Jun 2007 15:54:16 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCRC-0002gb-EC for manet@ietf.org; Tue, 12 Jun 2007 15:54:14 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l5CJrlI6006057; Tue, 12 Jun 2007 15:53:51 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007061215535008164 ; Tue, 12 Jun 2007 15:53:50 -0400 From: "Joe Macker" To: "'Mullen, John'" , References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr><4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens><466ED498.6090102@inria.fr> Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 15:53:48 -0400 Message-ID: <004c01c7ad2b$648475f0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcetF57/wWWtmXwKQRiJ4cNmt5n3iQABf6xgAAEeABA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Some 2 cents. Link state variants can be made more reactive and may provide other opportunities for robustness management. Also, MANET multicast may be = the better way to go for some network traffic in extreme edge temporal fragmentation cases or at least it should be considered. I think it = really depends on not just the scenario but the applications and traffic = patterns desired. A real user traffic model is needed to properly analyze and I don=92t buy general statements. Fuzzy-sighted approaches (also having = been done within OLSR implementations) have exhibited good scaling properties = and can be made to converge in different ways depending on the scenario requirements and assumptions. Previous analyses showed that for dense networks and networks with small relative diameters (8 hops or less) = that optimized flooding was a more important scaling feature than fuzzy = sighted methods but dynamic convergence properties needed more study. Reactive approaches can also be made more proactive (e.g., maintaining gateway routes,etc even when not on demand). For large networks, I think there = is some interesting additional work for someone to do regarding the = convergence potential of fuzzy-sighted or fisheye methods. This is outside the = present engineering WG charter but implementations already exist that work with = core WG designs. I believe spatial-temporal realtionship can be made more reactive in nature (to improve delay), but as Phillipe says even without that the route convergence can generally improve as one gets closer to = the destination. Certainly there is no one size fits all. Also rather than generalizing comparative analysis, one needs to think about protocol = control requirements under peak conditions as well (e.g., what happens when = everyone needs routes at once). In other words, a peak analysis may be more = important than average routing overhead analysis for some deployments and the fact that some MANET platforms have entire prefixes or sets of prefixes = behind them including possible heterogeneous interfaces (normal IP routing)... Also John, since you mentioned the ACK control tradeoff issue, if you = are interested the IETF MANET-OSPF design team did some evaluation on = examining tradeoffs between ACK-based control and best effort control propagation. -Joe >-----Original Message----- >From: Mullen, John [mailto:jomullen@ad.nmsu.edu]=20 >Sent: Tuesday, June 12, 2007 2:31 PM >To: manet@ietf.org >Subject: RE: [manet] DYMO and other routing protocols > >Agreed Philippe, > >My computations were greatly simplified. However, there is=20 >always a finite probability of error and it sounds like=20 >fisheye in OLSRD takes this into account. However, this is my concern. > >I work with MANETs that support critical operations, e.g.,=20 >military, disaster relief, fire fighting, etc. In these=20 >applications, the node distribution can be very uneven and=20 >quite dynamic, due to operational needs. For example,=20 >firefighters will place themselves along the perimeter of a=20 >forest fire and tend to work in uneven terrain. Hence, routes=20 >are likely to have little redundancy and even a small amount=20 >of movement could require a change, say if a node drops below=20 >a ridge. As a result, an error is more likely to manifest=20 >itself. In addition, there are people at risk and a loss of=20 >communications could have serious consequences. My feeling is=20 >that an acceptable MANET routing protocol needs to be robust=20 >enough that such errors do not cause an unnecessary failure.=20 >In addition, it is possible that such nets will become=20 >partitioned from time to time, so the protocol needs to be=20 >able to rejoin partitioned nets quickly. I think this is=20 >harder if a global link state approach is taken than if the=20 >long haul is reactive.=20 > >Bye for now, > >John P. Mullen, Ph.D. >(505) 646-2958 >jomullen@nmsu.edu >=20 >-----Original Message----- >From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] >Sent: Tuesday, June 12, 2007 11:15 AM >To: Mullen, John >Cc: manet@ietf.org >Subject: Re: [manet] DYMO and other routing protocols > >You are right that the information about a local link will=20 >have an increasing probability to be wrong when the distance=20 >increases. Not as dramatic as you suggest (because the number=20 >of path for the TC to reach a remote node also increases with=20 >distance and may correct the one path failure probability). In=20 >this case a node database will give you a "fisheye" view of=20 >the network: locally precise, more fuzzy at long distance. The=20 >impact is not dramatic because the route starting from far > takes the good direction and details about the local wrong=20 >links are resolved at the end. The path is thus very close to optimal. > >For this, you must activate the fisheye option, introduced by=20 >Gerla of UCLA and included in OLSR long time ago. This allows=20 >to deal with large network (with lot of hops and lot of=20 >nodes). The principle is that TCs with large TTL are=20 >transmitted less frequently but with larger time to live=20 >(otherwise remote nodes will timeout link set before a new TC=20 >arrive). Other advantage: the control overhead is reduced and=20 >scales better. > >This is included in the basic OLSRD codes and is used in=20 >practical implementation. > >Philippe > >Mullen, John a =E9crit : >> Good points! >>=20 >> If that were not enough, it is the nature of wireless=20 >communications that any transmission attempt may fail on a=20 >"working" link or be successful on a "non-working" one.=20 >Because there is always a finite probability of success on all=20 >links, one cannot be entirely sure which nodes actually get=20 >each updates, assuming they are sent UDP. If you use ACKs, on=20 >the other hand, there is the problem of deciding which node(s)=20 >decide when each update is complete and how that knowledge is=20 >made known to the network.=20 >>=20 >> I think this problem is manageable in a small, local net,=20 >but I'm not aware of a solution that is scalable to a MANET=20 >containing routes of four or more links. Between random=20 >variations in received signal strength due to fading and=20 >shadowing, local interference, overflowing buffers, and who=20 >knows what, the chances of every update reaching all nodes in=20 >a geographically large MANET are very small. Thus, it would be=20 >unlikely that all nodes would have the same image of the=20 >topology, meaning their tables would be inconsistent with each=20 >other and at odds with the real link states. For that reason,=20 >any proactive protocol needs to acknowledge that each node's=20 >tables are estimates of the actual link states and must be=20 >robust enough to deal with incomplete information. >>=20 >> This is one reason I think a hybrid approach would be=20 >advisable. Nodes in a one-, or maybe two-hop neighborhood=20 >could exchange link data frequently, e.g., by Hello messages,=20 >and would have a good chance of having locally consistent link=20 >state data. These tables could provide stable data as a basis=20 >for long-haul routes, improving the chances of a good route,=20 >and accomplish local repair. However, the overhead for=20 >informing an entire large MANET would be considerable. Aside=20 >from the larger number of links to update, because probability=20 >of end-to-end success decreases with the number of hops, all=20 >other things being equal, updates for distant nodes would have=20 >to be either ACKed or transmitted multiple times in order to=20 >have the same assurance that link data is correct globally as=20 >it would be locally. >>=20 >> To illustrate. >>=20 >> Suppose the probability of successful reception on a single hop is=20 >> 0.98 (Don't we wish!) and our standard is Pr(successful updates) >=3D = >> 0.95. Then, >>=20 >> # hops Pr(sucess in one try) minimum # tries for=20 >Pr(sucess) >=3D 0.95 >>=20 >> 1 0.980 0.77 -> 1 >> 2 0.960 0.93 -> 1 >> 3 0.941 1.06 -> 2 >> 4 0.922 1.17 -> 2 >> 5 0.904 1.28 -> 2 =20 >>=20 >> The actual degradation will depend on the actual=20 >probabilities, which can be expected to differ by link and=20 >change over time, but the principal will remain the same. More=20 >distant nodes will have a greater chance of not receiving=20 >updates. To compensate, one would either have to send multiple=20 >copies of the update or use ACKs. =20 >>=20 >> Node density also plays a role. If a node has four one-hop=20 >neighbors and the probability of success on each link is 0.98,=20 >the probability that all four of its neighbors receiving a=20 >single UDP update is only 0.92. If we modify the standard to=20 >require that the probability of all nodes receiving the update=20 >be at least 0.95, now one needs two transmissions of each=20 >update just to meet the standard in the one-hop neighborhood.=20 >Going further not only increases the number of hops, but also=20 >the number of nodes, so at some point, the overhead would=20 >become impractically high. Additionally, sending multiple=20 >copies of an update or using ACKs will increase the average=20 >time to propagate the updates, which will increase the risk=20 >that the update itself is actually no longer valid. And that=20 >is just to be 95% sure that all nodes have current data. There=20 >is still a 5% chance that any random node will have invalid data.=20 >>=20 >> The number of updates also affects the situation. Suppose=20 >there are ten updates a minute, each containing only the=20 >changed information, not the complete set of MANET link=20 >states, and the probability that each update is successful is=20 >0.95. The probability that all nodes will have correct data=20 >from all ten of the changes that occurred in that one minute,=20 >after enough time has passed to propagate the updates, is only=20 >about 0.6. >>=20 >> Although the actual numbers may differ, there will always be=20 >some probability of failure on an attempt on any link, so=20 >there will always be a sizable chance that any random node=20 >will have incorrect link state data. Reducing the maximum=20 >probability of invalid data increases the difficulty of=20 >meeting that standard exponentially. Reducing it to zero is impossible. >>=20 >> Bottom line: To be successful in a wireless MANET, the=20 >routing protocol needs to live with the fact that any tabled=20 >information may not be current and have mechanisms to deal=20 >with that possibility. >>=20 >> John P. Mullen, Ph.D. >> (505) 646-2958 >> jomullen@nmsu.edu >> =20 >> -----Original Message----- >> From: Herbert Rubens [mailto:hrubens@persistentsystems.com] >> Sent: Tuesday, June 12, 2007 6:54 AM >> To: 'Philippe Jacquet'; 'Charles E. Perkins' >> Cc: manet@ietf.org; manet-dt@ietf.org >> Subject: RE: [manet] DYMO and other routing protocols >>=20 >> Philippe, >>=20 >> Correct me if I am wrong, but Link-State protocols=20 >(e.g. OLSR) are=20 >> generally not 'instantaneously loop free'. Meaning if a link metric=20 >> changes or a link goes from working to not working, the link-state=20 >> database is not loop free until an update is received by all=20 >of the nodes in the network. >> Consider a simple example: if data is flowing along a path=20 >and a node=20 >> along the path decides that the next-hop link is no longer=20 >working. If it removes >> the link from the data-base and re-computes the path,=20 >the route might be >> back to the node that sent it the packet. Until that node=20 >receives an=20 >> update you will have a loop in the network. >>=20 >> It appears that when a link fails on an active=20 >link-state path, you=20 >> technically can't be routing reliably without a flood=20 >propagating the=20 >> entire network. In an on-demand (dymo, aodv, dsr) protocol, when a=20 >> link fails on an active path you also need to propagate a=20 >flood to the=20 >> entire network before the routing can continue. So while link-state=20 >> protocols actively track every imaginable path, it's not clear that=20 >> they actually perform differently in the link-failure case=20 >that you suggested. >>=20 >> -Herb >>=20 >> -----Original Message----- >> From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] >> Sent: Tuesday, June 12, 2007 5:32 AM >> To: Charles E. Perkins >> Cc: manet@ietf.org; manet-dt@ietf.org >> Subject: Re: [manet] DYMO and other routing protocols >>=20 >> Dear Charlie, >>=20 >> Sorry to have been kind of elliptic in my previous post. I=20 >didn't want=20 >> to mystify you;-) >>=20 >> In proactive protocols, when a link fails the alternative route is=20 >> immediately available, because it is already stored in the database. >> This what I call space diversity or space discrimination.=20 >The quantity=20 >> of information needed to this space diversity is controled=20 >by several=20 >> algorithms, the MPRs in OLSR is one example. This what I=20 >tried to name=20 >> space adaptability. >>=20 >> In DYMO when a route fails, a new route is created with a=20 >new sequence=20 >> number. The two routes don't exist simultaneously and it=20 >takes time to=20 >> recover. This is what I tried to name time discremination. >>=20 >> But I don't see time adaptability in DYMO. For example if a route=20 >> discovery fails it takes time to initiate a new route=20 >discovery. This=20 >> time should be controlled. Longer routes will have larger route=20 >> discovery delays, therefore need larger waiting time. However longer=20 >> route may have larger RREQ/RREP failure, therefore=20 >experience multiple=20 >> discovery route. In this case the waiting time should also=20 >be smaller=20 >> in order to minimize the delay to support multiple route discoveries. >> Shorter waiting time may create broacast congestion and failure on=20 >> other routes which is a killing situation. Here, serious time=20 >> adaptability is missing. The exponential backoff won't help. >>=20 >> The case with unidirectional links is a straightforward example.=20 >> Assume a node C with a strong transmission power and all other nodes=20 >> with lower power. Node C is on the path between a node A and=20 >a node B.=20 >> Assume that node C has, say, 10 unidirectional neighbors on=20 >that path=20 >> toward B. The first RREQ from A to B will go through C and via these=20 >> neighbors and in return the RREP will fail on one of these=20 >neighbors.=20 >> The later will list node C in its blacklist. After an=20 >initial waiting=20 >> time, node A will issue a new RREQ and the RREP will in=20 >return go via=20 >> another unidirectional neighor (since the first blacklisted=20 >link is denied): >> therefore a second blacklisted link. And so forth until all=20 >> unidirectional links have been blacklisted one by one: 10 route=20 >> discoveries attempt. Applying binary exponential backoff, you will=20 >> experience a delay larger than 1,000 times the initial route=20 >discovery=20 >> interval time. >>=20 >> If meanwhile one of the unidirectional neighbor un-blacklist=20 >its links=20 >> (this the only way to check if the link is now symmetric), then the=20 >> route discovery process may never end nor succeed. The blacklist=20 >> period (not specified in the draft) should be longer than the route=20 >> discovery delay. >>=20 >> It seems that DYMO shows some fragility with respect to timers. I=20 >> think it would be good to specify at least some strong adaptability=20 >> algorithms to correct this. I don't think you need to pickup from=20 >> proactive protocols for this end. >>=20 >> Below some links to real experiments where problems with=20 >recovery time=20 >> occurred. >>=20 >>=20 >> http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV >> http://www.seattlewireless.net/OpenWrt >>=20 >>=20 >>=20 >> Charles E. Perkins a =E9crit : >>> Hello Philippe, >>> >>> I really want to understand your point, but I confess that I am=20 >>> somewhat mystified and not yet getting it. >>> >>> How does OLSR adapt to "space"? Do you mean Euclidean space with=20 >>> constant radio range? I can just see the point about topology=20 >>> (because of MPRs), but I think we should insist that both DYMO and=20 >>> OLSR be equally able to utilize some SMF (or, lately for us, SMURF)=20 >>> ways of flooding over reduced relay sets. >>> >>> As I understand this, the common dependence on a reduced relay set=20 >>> will give both proactive and reactive approaches equal adaptability=20 >>> to topology. But this still doesn't enlighten me about=20 >adaptability=20 >>> in space. >>> >>> Regarding the adaptability in time... >>> >>> DYMO has the following time-based dependencies >>> - route timeouts >>> - shifting route discovery anywhere up to and >>> including application launch >>> - some second order effects about sequence >>> numbers. >>> I can definitely see a role for a new extension which enables nodes=20 >>> in a path to specify a non-default value for the route=20 >timeout. But=20 >>> it is not clear to me that this is what you are referring=20 >to. Could=20 >>> you be a bit more explicit? >>> >>> Anyway, this note is a long way of asking for more details, and I=20 >>> hope you won't mind having a longer discussion about it. >>> >>> Finally, if you would care to point out cases where DYMO performs=20 >>> poorly, but which are not able to be explained by reliance on=20 >>> brute-force flooding, it would be appreciated. I know=20 >about the case=20 >>> of fully-connected traffic patterns, and a few other corner cases,=20 >>> but somehow I feel you may have something else in mind. >>> >>> Regards, >>> Charlie P. >>> >>> >>> ext Philippe Jacquet wrote: >>>> I would say that from a very broad perspective, on-demand=20 >protocols=20 >>>> discriminate routes with respect to time and proactive protocols=20 >>>> discriminate routes with respect to space. Personnally I have=20 >>>> preference to proactive approach because it is richer and gives=20 >>>> better internet legacy. Objectively the two approaches have their=20 >>>> advantages and drawbacks and the two should be considered. >>>> >>>> This said, I don't think that on-demand and proactive=20 >approaches are=20 >>>> represented at the same level in MANET. OLSRv2 has "space" >>>> adaptability: i.e algorithms which automatically adapt to=20 >space and=20 >>>> topology variety, including for instance the MPR=20 >mechanism. In DYMO=20 >>>> I don't see an equivalent "time" adaptibility that goes beyond the=20 >>>> default values in timers. I think this may explain why the=20 >protocol=20 >>>> performs great in some scenario and very poorly in other. >>>> >>>> Some adaptability feature in DYMO would be welcome, not=20 >necessarily=20 >>>> proactive, but at least some memory based feature could help. >>>> >>>> Philippe >>>> >>>> David Murray a =E9crit : >>>>> Hi, >>>>> >>>>> I am wondering how DYMO fits in with the other routing=20 >protocols. I=20 >>>>> have read a number of papers that discuss how on-demand routing=20 >>>>> protocols like DSR/AODV work better in highly mobile environments=20 >>>>> where movement is fast, CPU and memory are low and batteries are=20 >>>>> limited. Equally, in situations where movement is very low, and=20 >>>>> there are no power limitations, protocols like=20 >OLSR/TBRPF/STAR perform better. >>>>> >>>>> So, I have a mental picture of OLSR/TBRPF being=20 >predominantly used=20 >>>>> in stationary 802.11 mesh devices and AODV/DYMO being used to=20 >>>>> connect users mobile devices ush as phones and PDAs. Is this=20 >>>>> correct or are things not quite as simple as this? (I=20 >know RFC 2501=20 >>>>> discusses MANET applications and characteristics but the=20 >discussion=20 >>>>> is quite general) >>>>> >>>>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>>>> very similar situations (the ad hoc interconnect between users=20 >>>>> devices). I am aware that DYMO is a simplified version of=20 >AODV both=20 >>>>> in code and network operation. It seems like the major difference=20 >>>>> is the path accumulation feature in DYMO which allows nodes to=20 >>>>> append their information to a RREP to give other nodes better=20 >>>>> knowledge of the topology. It also seems that the hello=20 >feature has=20 >>>>> been removed in DYMO. So, is DYMO likely to be a replacement for=20 >>>>> AODV or do they have different uses/applications? >>>>> >>>>> Thanks for your time >>>>> >>>>> Dave >>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/manet >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet >>> >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >>=20 >>=20 > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 12 16:47:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDGX-0000Ym-6W; Tue, 12 Jun 2007 16:47:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyDGV-0000Yf-4u for manet-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 16:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDGU-0000YV-RH for manet@ietf.org; Tue, 12 Jun 2007 16:46:58 -0400 Received: from exchange-fe1a.nmsu.edu ([128.123.34.178] helo=exchange-fe1.ACN.ad.nmsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDGT-0005ni-QX for manet@ietf.org; Tue, 12 Jun 2007 16:46:58 -0400 Received: from EXCHANGE-BE1.ACN.ad.nmsu.edu ([128.123.34.119]) by exchange-fe1.ACN.ad.nmsu.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:46:57 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Tue, 12 Jun 2007 14:46:54 -0600 Message-ID: In-Reply-To: <004c01c7ad2b$648475f0$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [manet] DYMO and other routing protocols Thread-index: AcetF57/wWWtmXwKQRiJ4cNmt5n3iQABf6xgAAEeABAABAKHoA== References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr><4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens><466ED498.6090102@inria.fr> <004c01c7ad2b$648475f0$165cfa84@SEXTANT> From: "Mullen, John" To: X-OriginalArrivalTime: 12 Jun 2007 20:46:57.0130 (UTC) FILETIME=[D1178CA0:01C7AD32] X-Spam-Score: 0.0 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Joe, =20 That's interesting. One approach I've seen is implicit ACKs. If A sends = to B and then hears B retransmitting the update, A knows B got it. ACKs = would only be needed in a few cases. For example, if B would not = normally retransmit the update or if A specifically requested an ACK.=20 Did the analysis consider that mechanism as well? John P. Mullen, Ph.D. (505) 646-2958 jomullen@nmsu.edu =20 -----Original Message----- From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 Sent: Tuesday, June 12, 2007 1:54 PM To: Mullen, John; manet@ietf.org Subject: RE: [manet] DYMO and other routing protocols Some 2 cents. Also John, since you mentioned the ACK control tradeoff issue, if you = are interested the IETF MANET-OSPF design team did some evaluation on = examining tradeoffs between ACK-based control and best effort control propagation. -Joe >-----Original Message----- >From: Mullen, John [mailto:jomullen@ad.nmsu.edu]=20 >Sent: Tuesday, June 12, 2007 2:31 PM >To: manet@ietf.org >Subject: RE: [manet] DYMO and other routing protocols > >Agreed Philippe, > >My computations were greatly simplified. However, there is=20 >always a finite probability of error and it sounds like=20 >fisheye in OLSRD takes this into account. However, this is my concern. > >I work with MANETs that support critical operations, e.g.,=20 >military, disaster relief, fire fighting, etc. In these=20 >applications, the node distribution can be very uneven and=20 >quite dynamic, due to operational needs. For example,=20 >firefighters will place themselves along the perimeter of a=20 >forest fire and tend to work in uneven terrain. Hence, routes=20 >are likely to have little redundancy and even a small amount=20 >of movement could require a change, say if a node drops below=20 >a ridge. As a result, an error is more likely to manifest=20 >itself. In addition, there are people at risk and a loss of=20 >communications could have serious consequences. My feeling is=20 >that an acceptable MANET routing protocol needs to be robust=20 >enough that such errors do not cause an unnecessary failure.=20 >In addition, it is possible that such nets will become=20 >partitioned from time to time, so the protocol needs to be=20 >able to rejoin partitioned nets quickly. I think this is=20 >harder if a global link state approach is taken than if the=20 >long haul is reactive.=20 > >Bye for now, > >John P. Mullen, Ph.D. >(505) 646-2958 >jomullen@nmsu.edu >=20 >-----Original Message----- >From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] >Sent: Tuesday, June 12, 2007 11:15 AM >To: Mullen, John >Cc: manet@ietf.org >Subject: Re: [manet] DYMO and other routing protocols > >You are right that the information about a local link will=20 >have an increasing probability to be wrong when the distance=20 >increases. Not as dramatic as you suggest (because the number=20 >of path for the TC to reach a remote node also increases with=20 >distance and may correct the one path failure probability). In=20 >this case a node database will give you a "fisheye" view of=20 >the network: locally precise, more fuzzy at long distance. The=20 >impact is not dramatic because the route starting from far > takes the good direction and details about the local wrong=20 >links are resolved at the end. The path is thus very close to optimal. > >For this, you must activate the fisheye option, introduced by=20 >Gerla of UCLA and included in OLSR long time ago. This allows=20 >to deal with large network (with lot of hops and lot of=20 >nodes). The principle is that TCs with large TTL are=20 >transmitted less frequently but with larger time to live=20 >(otherwise remote nodes will timeout link set before a new TC=20 >arrive). Other advantage: the control overhead is reduced and=20 >scales better. > >This is included in the basic OLSRD codes and is used in=20 >practical implementation. > >Philippe > >Mullen, John a =E9crit : >> Good points! >>=20 >> If that were not enough, it is the nature of wireless=20 >communications that any transmission attempt may fail on a=20 >"working" link or be successful on a "non-working" one.=20 >Because there is always a finite probability of success on all=20 >links, one cannot be entirely sure which nodes actually get=20 >each updates, assuming they are sent UDP. If you use ACKs, on=20 >the other hand, there is the problem of deciding which node(s)=20 >decide when each update is complete and how that knowledge is=20 >made known to the network.=20 >>=20 >> I think this problem is manageable in a small, local net,=20 >but I'm not aware of a solution that is scalable to a MANET=20 >containing routes of four or more links. Between random=20 >variations in received signal strength due to fading and=20 >shadowing, local interference, overflowing buffers, and who=20 >knows what, the chances of every update reaching all nodes in=20 >a geographically large MANET are very small. Thus, it would be=20 >unlikely that all nodes would have the same image of the=20 >topology, meaning their tables would be inconsistent with each=20 >other and at odds with the real link states. For that reason,=20 >any proactive protocol needs to acknowledge that each node's=20 >tables are estimates of the actual link states and must be=20 >robust enough to deal with incomplete information. >>=20 >> This is one reason I think a hybrid approach would be=20 >advisable. Nodes in a one-, or maybe two-hop neighborhood=20 >could exchange link data frequently, e.g., by Hello messages,=20 >and would have a good chance of having locally consistent link=20 >state data. These tables could provide stable data as a basis=20 >for long-haul routes, improving the chances of a good route,=20 >and accomplish local repair. However, the overhead for=20 >informing an entire large MANET would be considerable. Aside=20 >from the larger number of links to update, because probability=20 >of end-to-end success decreases with the number of hops, all=20 >other things being equal, updates for distant nodes would have=20 >to be either ACKed or transmitted multiple times in order to=20 >have the same assurance that link data is correct globally as=20 >it would be locally. >>=20 >> To illustrate. >>=20 >> Suppose the probability of successful reception on a single hop is=20 >> 0.98 (Don't we wish!) and our standard is Pr(successful updates) >=3D = >> 0.95. Then, >>=20 >> # hops Pr(sucess in one try) minimum # tries for=20 >Pr(sucess) >=3D 0.95 >>=20 >> 1 0.980 0.77 -> 1 >> 2 0.960 0.93 -> 1 >> 3 0.941 1.06 -> 2 >> 4 0.922 1.17 -> 2 >> 5 0.904 1.28 -> 2 =20 >>=20 >> The actual degradation will depend on the actual=20 >probabilities, which can be expected to differ by link and=20 >change over time, but the principal will remain the same. More=20 >distant nodes will have a greater chance of not receiving=20 >updates. To compensate, one would either have to send multiple=20 >copies of the update or use ACKs. =20 >>=20 >> Node density also plays a role. If a node has four one-hop=20 >neighbors and the probability of success on each link is 0.98,=20 >the probability that all four of its neighbors receiving a=20 >single UDP update is only 0.92. If we modify the standard to=20 >require that the probability of all nodes receiving the update=20 >be at least 0.95, now one needs two transmissions of each=20 >update just to meet the standard in the one-hop neighborhood.=20 >Going further not only increases the number of hops, but also=20 >the number of nodes, so at some point, the overhead would=20 >become impractically high. Additionally, sending multiple=20 >copies of an update or using ACKs will increase the average=20 >time to propagate the updates, which will increase the risk=20 >that the update itself is actually no longer valid. And that=20 >is just to be 95% sure that all nodes have current data. There=20 >is still a 5% chance that any random node will have invalid data.=20 >>=20 >> The number of updates also affects the situation. Suppose=20 >there are ten updates a minute, each containing only the=20 >changed information, not the complete set of MANET link=20 >states, and the probability that each update is successful is=20 >0.95. The probability that all nodes will have correct data=20 >from all ten of the changes that occurred in that one minute,=20 >after enough time has passed to propagate the updates, is only=20 >about 0.6. >>=20 >> Although the actual numbers may differ, there will always be=20 >some probability of failure on an attempt on any link, so=20 >there will always be a sizable chance that any random node=20 >will have incorrect link state data. Reducing the maximum=20 >probability of invalid data increases the difficulty of=20 >meeting that standard exponentially. Reducing it to zero is impossible. >>=20 >> Bottom line: To be successful in a wireless MANET, the=20 >routing protocol needs to live with the fact that any tabled=20 >information may not be current and have mechanisms to deal=20 >with that possibility. >>=20 >> John P. Mullen, Ph.D. >> (505) 646-2958 >> jomullen@nmsu.edu >> =20 >> -----Original Message----- >> From: Herbert Rubens [mailto:hrubens@persistentsystems.com] >> Sent: Tuesday, June 12, 2007 6:54 AM >> To: 'Philippe Jacquet'; 'Charles E. Perkins' >> Cc: manet@ietf.org; manet-dt@ietf.org >> Subject: RE: [manet] DYMO and other routing protocols >>=20 >> Philippe, >>=20 >> Correct me if I am wrong, but Link-State protocols=20 >(e.g. OLSR) are=20 >> generally not 'instantaneously loop free'. Meaning if a link metric=20 >> changes or a link goes from working to not working, the link-state=20 >> database is not loop free until an update is received by all=20 >of the nodes in the network. >> Consider a simple example: if data is flowing along a path=20 >and a node=20 >> along the path decides that the next-hop link is no longer=20 >working. If it removes >> the link from the data-base and re-computes the path,=20 >the route might be >> back to the node that sent it the packet. Until that node=20 >receives an=20 >> update you will have a loop in the network. >>=20 >> It appears that when a link fails on an active=20 >link-state path, you=20 >> technically can't be routing reliably without a flood=20 >propagating the=20 >> entire network. In an on-demand (dymo, aodv, dsr) protocol, when a=20 >> link fails on an active path you also need to propagate a=20 >flood to the=20 >> entire network before the routing can continue. So while link-state=20 >> protocols actively track every imaginable path, it's not clear that=20 >> they actually perform differently in the link-failure case=20 >that you suggested. >>=20 >> -Herb >>=20 >> -----Original Message----- >> From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] >> Sent: Tuesday, June 12, 2007 5:32 AM >> To: Charles E. Perkins >> Cc: manet@ietf.org; manet-dt@ietf.org >> Subject: Re: [manet] DYMO and other routing protocols >>=20 >> Dear Charlie, >>=20 >> Sorry to have been kind of elliptic in my previous post. I=20 >didn't want=20 >> to mystify you;-) >>=20 >> In proactive protocols, when a link fails the alternative route is=20 >> immediately available, because it is already stored in the database. >> This what I call space diversity or space discrimination.=20 >The quantity=20 >> of information needed to this space diversity is controled=20 >by several=20 >> algorithms, the MPRs in OLSR is one example. This what I=20 >tried to name=20 >> space adaptability. >>=20 >> In DYMO when a route fails, a new route is created with a=20 >new sequence=20 >> number. The two routes don't exist simultaneously and it=20 >takes time to=20 >> recover. This is what I tried to name time discremination. >>=20 >> But I don't see time adaptability in DYMO. For example if a route=20 >> discovery fails it takes time to initiate a new route=20 >discovery. This=20 >> time should be controlled. Longer routes will have larger route=20 >> discovery delays, therefore need larger waiting time. However longer=20 >> route may have larger RREQ/RREP failure, therefore=20 >experience multiple=20 >> discovery route. In this case the waiting time should also=20 >be smaller=20 >> in order to minimize the delay to support multiple route discoveries. >> Shorter waiting time may create broacast congestion and failure on=20 >> other routes which is a killing situation. Here, serious time=20 >> adaptability is missing. The exponential backoff won't help. >>=20 >> The case with unidirectional links is a straightforward example.=20 >> Assume a node C with a strong transmission power and all other nodes=20 >> with lower power. Node C is on the path between a node A and=20 >a node B.=20 >> Assume that node C has, say, 10 unidirectional neighbors on=20 >that path=20 >> toward B. The first RREQ from A to B will go through C and via these=20 >> neighbors and in return the RREP will fail on one of these=20 >neighbors.=20 >> The later will list node C in its blacklist. After an=20 >initial waiting=20 >> time, node A will issue a new RREQ and the RREP will in=20 >return go via=20 >> another unidirectional neighor (since the first blacklisted=20 >link is denied): >> therefore a second blacklisted link. And so forth until all=20 >> unidirectional links have been blacklisted one by one: 10 route=20 >> discoveries attempt. Applying binary exponential backoff, you will=20 >> experience a delay larger than 1,000 times the initial route=20 >discovery=20 >> interval time. >>=20 >> If meanwhile one of the unidirectional neighbor un-blacklist=20 >its links=20 >> (this the only way to check if the link is now symmetric), then the=20 >> route discovery process may never end nor succeed. The blacklist=20 >> period (not specified in the draft) should be longer than the route=20 >> discovery delay. >>=20 >> It seems that DYMO shows some fragility with respect to timers. I=20 >> think it would be good to specify at least some strong adaptability=20 >> algorithms to correct this. I don't think you need to pickup from=20 >> proactive protocols for this end. >>=20 >> Below some links to real experiments where problems with=20 >recovery time=20 >> occurred. >>=20 >>=20 >> http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV >> http://www.seattlewireless.net/OpenWrt >>=20 >>=20 >>=20 >> Charles E. Perkins a =E9crit : >>> Hello Philippe, >>> >>> I really want to understand your point, but I confess that I am=20 >>> somewhat mystified and not yet getting it. >>> >>> How does OLSR adapt to "space"? Do you mean Euclidean space with=20 >>> constant radio range? I can just see the point about topology=20 >>> (because of MPRs), but I think we should insist that both DYMO and=20 >>> OLSR be equally able to utilize some SMF (or, lately for us, SMURF)=20 >>> ways of flooding over reduced relay sets. >>> >>> As I understand this, the common dependence on a reduced relay set=20 >>> will give both proactive and reactive approaches equal adaptability=20 >>> to topology. But this still doesn't enlighten me about=20 >adaptability=20 >>> in space. >>> >>> Regarding the adaptability in time... >>> >>> DYMO has the following time-based dependencies >>> - route timeouts >>> - shifting route discovery anywhere up to and >>> including application launch >>> - some second order effects about sequence >>> numbers. >>> I can definitely see a role for a new extension which enables nodes=20 >>> in a path to specify a non-default value for the route=20 >timeout. But=20 >>> it is not clear to me that this is what you are referring=20 >to. Could=20 >>> you be a bit more explicit? >>> >>> Anyway, this note is a long way of asking for more details, and I=20 >>> hope you won't mind having a longer discussion about it. >>> >>> Finally, if you would care to point out cases where DYMO performs=20 >>> poorly, but which are not able to be explained by reliance on=20 >>> brute-force flooding, it would be appreciated. I know=20 >about the case=20 >>> of fully-connected traffic patterns, and a few other corner cases,=20 >>> but somehow I feel you may have something else in mind. >>> >>> Regards, >>> Charlie P. >>> >>> >>> ext Philippe Jacquet wrote: >>>> I would say that from a very broad perspective, on-demand=20 >protocols=20 >>>> discriminate routes with respect to time and proactive protocols=20 >>>> discriminate routes with respect to space. Personnally I have=20 >>>> preference to proactive approach because it is richer and gives=20 >>>> better internet legacy. Objectively the two approaches have their=20 >>>> advantages and drawbacks and the two should be considered. >>>> >>>> This said, I don't think that on-demand and proactive=20 >approaches are=20 >>>> represented at the same level in MANET. OLSRv2 has "space" >>>> adaptability: i.e algorithms which automatically adapt to=20 >space and=20 >>>> topology variety, including for instance the MPR=20 >mechanism. In DYMO=20 >>>> I don't see an equivalent "time" adaptibility that goes beyond the=20 >>>> default values in timers. I think this may explain why the=20 >protocol=20 >>>> performs great in some scenario and very poorly in other. >>>> >>>> Some adaptability feature in DYMO would be welcome, not=20 >necessarily=20 >>>> proactive, but at least some memory based feature could help. >>>> >>>> Philippe >>>> >>>> David Murray a =E9crit : >>>>> Hi, >>>>> >>>>> I am wondering how DYMO fits in with the other routing=20 >protocols. I=20 >>>>> have read a number of papers that discuss how on-demand routing=20 >>>>> protocols like DSR/AODV work better in highly mobile environments=20 >>>>> where movement is fast, CPU and memory are low and batteries are=20 >>>>> limited. Equally, in situations where movement is very low, and=20 >>>>> there are no power limitations, protocols like=20 >OLSR/TBRPF/STAR perform better. >>>>> >>>>> So, I have a mental picture of OLSR/TBRPF being=20 >predominantly used=20 >>>>> in stationary 802.11 mesh devices and AODV/DYMO being used to=20 >>>>> connect users mobile devices ush as phones and PDAs. Is this=20 >>>>> correct or are things not quite as simple as this? (I=20 >know RFC 2501=20 >>>>> discusses MANET applications and characteristics but the=20 >discussion=20 >>>>> is quite general) >>>>> >>>>> If this is correct, it seems to me that DYMO and AODV are used in=20 >>>>> very similar situations (the ad hoc interconnect between users=20 >>>>> devices). I am aware that DYMO is a simplified version of=20 >AODV both=20 >>>>> in code and network operation. It seems like the major difference=20 >>>>> is the path accumulation feature in DYMO which allows nodes to=20 >>>>> append their information to a RREP to give other nodes better=20 >>>>> knowledge of the topology. It also seems that the hello=20 >feature has=20 >>>>> been removed in DYMO. So, is DYMO likely to be a replacement for=20 >>>>> AODV or do they have different uses/applications? >>>>> >>>>> Thanks for your time >>>>> >>>>> Dave >>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/manet >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet >>> >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >>=20 >>=20 > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 13 11:26:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUjN-0002o4-DL; Wed, 13 Jun 2007 11:25:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyUjL-0002nw-NT for manet-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 11:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUjL-0002nn-Di for manet@ietf.org; Wed, 13 Jun 2007 11:25:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUjJ-0003f5-9u for manet@ietf.org; Wed, 13 Jun 2007 11:25:55 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2007 08:25:52 -0700 X-IronPort-AV: i="4.16,417,1175497200"; d="scan'208"; a="164071301:sNHT85620204" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5DFPquX011588; Wed, 13 Jun 2007 08:25:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5DFPnaO003740; Wed, 13 Jun 2007 15:25:50 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 08:25:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] DYMO and other routing protocols Date: Wed, 13 Jun 2007 08:26:10 -0700 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A026CE158@xmb-sjc-219.amer.cisco.com> In-Reply-To: <466ED498.6090102@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DYMO and other routing protocols Thread-Index: AcetFUNkboQ4ItxST52P13tKap8T3AAuTxvw From: "Krishna Sankar \(ksankar\)" To: "Philippe Jacquet" , "Mullen, John" X-OriginalArrivalTime: 13 Jun 2007 15:25:49.0587 (UTC) FILETIME=[1F278E30:01C7ADCF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18805; t=1181748352; x=1182612352; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ksankar@cisco.com; z=From:=20=22Krishna=20Sankar=20\(ksankar\)=22=20 |Subject:=20RE=3A=20[manet]=20DYMO=20and=20other=20routing=20protocols |Sender:=20; bh=vrkuGADMiWvUvoaunRjaf5pEEj3T7Bq0k4qMzgvNOy8=; b=fanX6d3U1ZCxGddLFE/IGaek39l5Wjg0o3X20846dL2UJXSctFH1ZcjCNPEj68JK6lmhWNmu vKmLLPek6WZBRicviJHF3/mfXlv6kayzaBAO2MCuUKUNtZMmSRwTxFd3dkxjJSJwiBg4emzqdz /tKlx757Vy2Ba/V4mfTcAomeg=; Authentication-Results: sj-dkim-1; header.From=ksankar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Yep, the fisheye mechanisms are well suited for this domain. I think = this is the option in 802.11s as well. I haven't gone thru the latest = draft in detail, but am pretty sure. BTW, has there been any studies on = DYMO for 802.11s ?=20 Cheers =20 > -----Original Message----- > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 > Sent: Tuesday, June 12, 2007 10:15 AM > To: Mullen, John > Cc: manet@ietf.org > Subject: Re: [manet] DYMO and other routing protocols >=20 > You are right that the information about a local link will=20 > have an increasing probability to be wrong when the distance=20 > increases. Not as dramatic as you suggest (because the number=20 > of path for the TC to reach a remote node also increases with=20 > distance and may correct the one path failure probability).=20 > In this case a node database will give you a "fisheye" view=20 > of the network: locally precise, more fuzzy at long distance.=20 > The impact is not dramatic because the route starting from far > takes the good direction and details about the local wrong=20 > links are resolved at the end. The path is thus very close to optimal. >=20 > For this, you must activate the fisheye option, introduced by=20 > Gerla of UCLA and included in OLSR long time ago. This allows=20 > to deal with large network (with lot of hops and lot of=20 > nodes). The principle is that TCs with large TTL are=20 > transmitted less frequently but with larger time to live=20 > (otherwise remote nodes will timeout link set before a new TC=20 > arrive). Other advantage: the control overhead is reduced and=20 > scales better. >=20 > This is included in the basic OLSRD codes and is used in=20 > practical implementation. >=20 > Philippe >=20 > Mullen, John a =E9crit : > > Good points! > >=20 > > If that were not enough, it is the nature of wireless=20 > communications that any transmission attempt may fail on a=20 > "working" link or be successful on a "non-working" one.=20 > Because there is always a finite probability of success on=20 > all links, one cannot be entirely sure which nodes actually=20 > get each updates, assuming they are sent UDP. If you use=20 > ACKs, on the other hand, there is the problem of deciding=20 > which node(s) decide when each update is complete and how=20 > that knowledge is made known to the network.=20 > >=20 > > I think this problem is manageable in a small, local net,=20 > but I'm not aware of a solution that is scalable to a MANET=20 > containing routes of four or more links. Between random=20 > variations in received signal strength due to fading and=20 > shadowing, local interference, overflowing buffers, and who=20 > knows what, the chances of every update reaching all nodes in=20 > a geographically large MANET are very small. Thus, it would=20 > be unlikely that all nodes would have the same image of the=20 > topology, meaning their tables would be inconsistent with=20 > each other and at odds with the real link states. For that=20 > reason, any proactive protocol needs to acknowledge that each=20 > node's tables are estimates of the actual link states and=20 > must be robust enough to deal with incomplete information. > >=20 > > This is one reason I think a hybrid approach would be=20 > advisable. Nodes in a one-, or maybe two-hop neighborhood=20 > could exchange link data frequently, e.g., by Hello messages,=20 > and would have a good chance of having locally consistent=20 > link state data. These tables could provide stable data as a=20 > basis for long-haul routes, improving the chances of a good=20 > route, and accomplish local repair. However, the overhead for=20 > informing an entire large MANET would be considerable. Aside=20 > from the larger number of links to update, because=20 > probability of end-to-end success decreases with the number=20 > of hops, all other things being equal, updates for distant=20 > nodes would have to be either ACKed or transmitted multiple=20 > times in order to have the same assurance that link data is=20 > correct globally as it would be locally. > >=20 > > To illustrate. > >=20 > > Suppose the probability of successful reception on a single hop is=20 > > 0.98 (Don't we wish!) and our standard is Pr(successful updates) = >=3D=20 > > 0.95. Then, > >=20 > > # hops Pr(sucess in one try) minimum # tries for=20 > Pr(sucess) >=3D 0.95 > >=20 > > 1 0.980 0.77 -> 1 > > 2 0.960 0.93 -> 1 > > 3 0.941 1.06 -> 2 > > 4 0.922 1.17 -> 2 > > 5 0.904 1.28 -> 2 =20 > >=20 > > The actual degradation will depend on the actual=20 > probabilities, which can be expected to differ by link and=20 > change over time, but the principal will remain the same.=20 > More distant nodes will have a greater chance of not=20 > receiving updates. To compensate, one would either have to=20 > send multiple copies of the update or use ACKs. =20 > >=20 > > Node density also plays a role. If a node has four one-hop=20 > neighbors and the probability of success on each link is=20 > 0.98, the probability that all four of its neighbors=20 > receiving a single UDP update is only 0.92. If we modify the=20 > standard to require that the probability of all nodes=20 > receiving the update be at least 0.95, now one needs two=20 > transmissions of each update just to meet the standard in the=20 > one-hop neighborhood. Going further not only increases the=20 > number of hops, but also the number of nodes, so at some=20 > point, the overhead would become impractically high.=20 > Additionally, sending multiple copies of an update or using=20 > ACKs will increase the average time to propagate the updates,=20 > which will increase the risk that the update itself is=20 > actually no longer valid. And that is just to be 95% sure=20 > that all nodes have current data. There is still a 5% chance=20 > that any random node will have invalid data.=20 > >=20 > > The number of updates also affects the situation. Suppose=20 > there are ten updates a minute, each containing only the=20 > changed information, not the complete set of MANET link=20 > states, and the probability that each update is successful is=20 > 0.95. The probability that all nodes will have correct data=20 > from all ten of the changes that occurred in that one minute,=20 > after enough time has passed to propagate the updates, is=20 > only about 0.6. > >=20 > > Although the actual numbers may differ, there will always=20 > be some probability of failure on an attempt on any link, so=20 > there will always be a sizable chance that any random node=20 > will have incorrect link state data. Reducing the maximum=20 > probability of invalid data increases the difficulty of=20 > meeting that standard exponentially. Reducing it to zero is=20 > impossible. > >=20 > > Bottom line: To be successful in a wireless MANET, the=20 > routing protocol needs to live with the fact that any tabled=20 > information may not be current and have mechanisms to deal=20 > with that possibility. > >=20 > > John P. Mullen, Ph.D. > > (505) 646-2958 > > jomullen@nmsu.edu > > =20 > > -----Original Message----- > > From: Herbert Rubens [mailto:hrubens@persistentsystems.com] > > Sent: Tuesday, June 12, 2007 6:54 AM > > To: 'Philippe Jacquet'; 'Charles E. Perkins' > > Cc: manet@ietf.org; manet-dt@ietf.org > > Subject: RE: [manet] DYMO and other routing protocols > >=20 > > Philippe, > >=20 > > Correct me if I am wrong, but Link-State protocols=20 > (e.g. OLSR) are=20 > > generally not 'instantaneously loop free'. Meaning if a link metric=20 > > changes or a link goes from working to not working, the link-state=20 > > database is not loop free until an update is received by=20 > all of the nodes in the network. > > Consider a simple example: if data is flowing along a path=20 > and a node=20 > > along the path decides that the next-hop link is no longer=20 > working. If it removes > > the link from the data-base and re-computes the path,=20 > the route might be > > back to the node that sent it the packet. Until that node=20 > receives an=20 > > update you will have a loop in the network. > >=20 > > It appears that when a link fails on an active=20 > link-state path, you=20 > > technically can't be routing reliably without a flood=20 > propagating the=20 > > entire network. In an on-demand (dymo, aodv, dsr) protocol, when a=20 > > link fails on an active path you also need to propagate a=20 > flood to the=20 > > entire network before the routing can continue. So while link-state=20 > > protocols actively track every imaginable path, it's not clear that=20 > > they actually perform differently in the link-failure case=20 > that you suggested. > >=20 > > -Herb > >=20 > > -----Original Message----- > > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] > > Sent: Tuesday, June 12, 2007 5:32 AM > > To: Charles E. Perkins > > Cc: manet@ietf.org; manet-dt@ietf.org > > Subject: Re: [manet] DYMO and other routing protocols > >=20 > > Dear Charlie, > >=20 > > Sorry to have been kind of elliptic in my previous post. I=20 > didn't want=20 > > to mystify you;-) > >=20 > > In proactive protocols, when a link fails the alternative route is=20 > > immediately available, because it is already stored in the database. > > This what I call space diversity or space discrimination.=20 > The quantity=20 > > of information needed to this space diversity is controled=20 > by several=20 > > algorithms, the MPRs in OLSR is one example. This what I=20 > tried to name=20 > > space adaptability. > >=20 > > In DYMO when a route fails, a new route is created with a=20 > new sequence=20 > > number. The two routes don't exist simultaneously and it=20 > takes time to=20 > > recover. This is what I tried to name time discremination. > >=20 > > But I don't see time adaptability in DYMO. For example if a route=20 > > discovery fails it takes time to initiate a new route=20 > discovery. This=20 > > time should be controlled. Longer routes will have larger route=20 > > discovery delays, therefore need larger waiting time.=20 > However longer=20 > > route may have larger RREQ/RREP failure, therefore=20 > experience multiple=20 > > discovery route. In this case the waiting time should also=20 > be smaller=20 > > in order to minimize the delay to support multiple route=20 > discoveries. > > Shorter waiting time may create broacast congestion and failure on=20 > > other routes which is a killing situation. Here, serious time=20 > > adaptability is missing. The exponential backoff won't help. > >=20 > > The case with unidirectional links is a straightforward example.=20 > > Assume a node C with a strong transmission power and all=20 > other nodes=20 > > with lower power. Node C is on the path between a node A=20 > and a node B.=20 > > Assume that node C has, say, 10 unidirectional neighbors on=20 > that path=20 > > toward B. The first RREQ from A to B will go through C and=20 > via these=20 > > neighbors and in return the RREP will fail on one of these=20 > neighbors.=20 > > The later will list node C in its blacklist. After an=20 > initial waiting=20 > > time, node A will issue a new RREQ and the RREP will in=20 > return go via=20 > > another unidirectional neighor (since the first blacklisted=20 > link is denied): > > therefore a second blacklisted link. And so forth until all=20 > > unidirectional links have been blacklisted one by one: 10 route=20 > > discoveries attempt. Applying binary exponential backoff, you will=20 > > experience a delay larger than 1,000 times the initial=20 > route discovery=20 > > interval time. > >=20 > > If meanwhile one of the unidirectional neighbor=20 > un-blacklist its links=20 > > (this the only way to check if the link is now symmetric), then the=20 > > route discovery process may never end nor succeed. The blacklist=20 > > period (not specified in the draft) should be longer than the route=20 > > discovery delay. > >=20 > > It seems that DYMO shows some fragility with respect to timers. I=20 > > think it would be good to specify at least some strong adaptability=20 > > algorithms to correct this. I don't think you need to pickup from=20 > > proactive protocols for this end. > >=20 > > Below some links to real experiments where problems with=20 > recovery time=20 > > occurred. > >=20 > >=20 > > http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV > > http://www.seattlewireless.net/OpenWrt > >=20 > >=20 > >=20 > > Charles E. Perkins a =E9crit : > >> Hello Philippe, > >> > >> I really want to understand your point, but I confess that I am=20 > >> somewhat mystified and not yet getting it. > >> > >> How does OLSR adapt to "space"? Do you mean Euclidean space with=20 > >> constant radio range? I can just see the point about topology=20 > >> (because of MPRs), but I think we should insist that both DYMO and=20 > >> OLSR be equally able to utilize some SMF (or, lately for=20 > us, SMURF)=20 > >> ways of flooding over reduced relay sets. > >> > >> As I understand this, the common dependence on a reduced relay set=20 > >> will give both proactive and reactive approaches equal=20 > adaptability=20 > >> to topology. But this still doesn't enlighten me about=20 > adaptability=20 > >> in space. > >> > >> Regarding the adaptability in time... > >> > >> DYMO has the following time-based dependencies > >> - route timeouts > >> - shifting route discovery anywhere up to and > >> including application launch > >> - some second order effects about sequence > >> numbers. > >> I can definitely see a role for a new extension which=20 > enables nodes=20 > >> in a path to specify a non-default value for the route=20 > timeout. But=20 > >> it is not clear to me that this is what you are referring=20 > to. Could=20 > >> you be a bit more explicit? > >> > >> Anyway, this note is a long way of asking for more details, and I=20 > >> hope you won't mind having a longer discussion about it. > >> > >> Finally, if you would care to point out cases where DYMO performs=20 > >> poorly, but which are not able to be explained by reliance on=20 > >> brute-force flooding, it would be appreciated. I know=20 > about the case=20 > >> of fully-connected traffic patterns, and a few other corner cases,=20 > >> but somehow I feel you may have something else in mind. > >> > >> Regards, > >> Charlie P. > >> > >> > >> ext Philippe Jacquet wrote: > >>> I would say that from a very broad perspective, on-demand=20 > protocols=20 > >>> discriminate routes with respect to time and proactive protocols=20 > >>> discriminate routes with respect to space. Personnally I have=20 > >>> preference to proactive approach because it is richer and gives=20 > >>> better internet legacy. Objectively the two approaches have their=20 > >>> advantages and drawbacks and the two should be considered. > >>> > >>> This said, I don't think that on-demand and proactive=20 > approaches are=20 > >>> represented at the same level in MANET. OLSRv2 has "space" > >>> adaptability: i.e algorithms which automatically adapt to=20 > space and=20 > >>> topology variety, including for instance the MPR=20 > mechanism. In DYMO=20 > >>> I don't see an equivalent "time" adaptibility that goes=20 > beyond the=20 > >>> default values in timers. I think this may explain why=20 > the protocol=20 > >>> performs great in some scenario and very poorly in other. > >>> > >>> Some adaptability feature in DYMO would be welcome, not=20 > necessarily=20 > >>> proactive, but at least some memory based feature could help. > >>> > >>> Philippe > >>> > >>> David Murray a =E9crit : > >>>> Hi, > >>>> > >>>> I am wondering how DYMO fits in with the other routing=20 > protocols. I=20 > >>>> have read a number of papers that discuss how on-demand routing=20 > >>>> protocols like DSR/AODV work better in highly mobile=20 > environments=20 > >>>> where movement is fast, CPU and memory are low and batteries are=20 > >>>> limited. Equally, in situations where movement is very low, and=20 > >>>> there are no power limitations, protocols like=20 > OLSR/TBRPF/STAR perform better. > >>>> > >>>> So, I have a mental picture of OLSR/TBRPF being=20 > predominantly used=20 > >>>> in stationary 802.11 mesh devices and AODV/DYMO being used to=20 > >>>> connect users mobile devices ush as phones and PDAs. Is this=20 > >>>> correct or are things not quite as simple as this? (I=20 > know RFC 2501=20 > >>>> discusses MANET applications and characteristics but the=20 > discussion=20 > >>>> is quite general) > >>>> > >>>> If this is correct, it seems to me that DYMO and AODV=20 > are used in=20 > >>>> very similar situations (the ad hoc interconnect between users=20 > >>>> devices). I am aware that DYMO is a simplified version=20 > of AODV both=20 > >>>> in code and network operation. It seems like the major=20 > difference=20 > >>>> is the path accumulation feature in DYMO which allows nodes to=20 > >>>> append their information to a RREP to give other nodes better=20 > >>>> knowledge of the topology. It also seems that the hello=20 > feature has=20 > >>>> been removed in DYMO. So, is DYMO likely to be a replacement for=20 > >>>> AODV or do they have different uses/applications? > >>>> > >>>> Thanks for your time > >>>> > >>>> Dave > >>>> > >>>> > >>>> _______________________________________________ > >>>> manet mailing list > >>>> manet@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/manet > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/manet > >> > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 > >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 14 08:14:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyoDH-0002bN-A8; Thu, 14 Jun 2007 08:14:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HyoDF-0002a4-Fm for manet-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:14:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyoDF-0002Zs-66 for manet@ietf.org; Thu, 14 Jun 2007 08:14:05 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyoDB-000594-KC for manet@ietf.org; Thu, 14 Jun 2007 08:14:05 -0400 Received: from smtps.inrialpes.fr (smtps.inrialpes.fr [194.199.18.58]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id l5ECDomH000191; Thu, 14 Jun 2007 14:13:50 +0200 (MEST) Received: from [134.214.59.148] (wifinsa403.insa-lyon.fr [134.214.59.148]) (authenticated bits=0) by smtps.inrialpes.fr (8.13.7/8.13.4) with ESMTP id l5ECDosn002211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 14:13:50 +0200 Message-ID: <46713100.6010705@inria.fr> Date: Thu, 14 Jun 2007 14:13:52 +0200 From: "Prof. Eric Fleury CITI/ARES" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: asr.rescom@cines.fr, arp@cines.fr, manet@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Thu, 14 Jun 2007 14:13:52 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.001, requis 5, HTML_MESSAGE 0.00) X-mx-serv-inrialpes-fr-MailScanner-From: eric.fleury@inria.fr X-Spam-Status: No X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: Subject: [manet] call for paper: 3rd International Conference on Mobile Ad-hoc and Sensor Networks (MSN'07) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1169090152==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1169090152== Content-Type: multipart/alternative; boundary="------------090805080909080803080204" This is a multi-part message in MIME format. --------------090805080909080803080204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit CALL FOR PAPERS =================================================== The 3rd International Conference on Mobile Ad-hoc and Sensor Networks (MSN'07) 12-14 December 2007, Beijing, China http://conference.bjtu.edu.cn/msn07 Following the success of the past two conferences, MSN'05 in Wuhan, China and MSN'06 in Hong Kong, MSN'07 provides a forum for researchers and practitioners to exchange research results and share development experiences. Topics of interest include, but are not limited to, the following areas in mobile ad hoc and sensor networks: ? Network architecture and protocols ? Software platforms and development tools ? Self-organization and synchronization ? Routing and data dissemination ? Failure resilience and fault isolation ? Energy Management ? Data, information, and signal processing ? Security and privacy ? Network planning, provisioning, and deployment ? Developments and applications ? Integration with other system Paper submission: MSN invites authors to submit original and unpublished work. Submissions should include an abstract, key words, the e-mail address of the corresponding author, and must not exceed 15 pages, including tables and figures, with PDF, PostScript, or MSWord format. Electronic submission through the submission website is strongly encouraged. Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Important Days: ? Submission deadline: 30 June, 2007 ? Notification of acceptance: 10 August 2007 ? Final Manuscript due: 1 September 2007 ------------------------------------------------------------------------ -- Eric FLEURY PROF. AT INSA of LYON Co-HEAD OF CITI LAB & Co-Leader of ARES INRIA PROJECT TEL: +33 472 436 421/+33 672 162 974 FAX: +33 472 436 227 WEB: http://perso.citi.insa-lyon.fr/efleury/ --------------090805080909080803080204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
CALL FOR PAPERS
===================================================
The 3rd International Conference on Mobile Ad-hoc and Sensor Networks
(MSN'07)

12-14 December 2007, Beijing, China

http://conference.bjtu.edu.cn/msn07


Following the success of the past two conferences, MSN'05 in Wuhan, China
and MSN'06 in Hong Kong, MSN'07 provides a forum for researchers and
practitioners to exchange research results and share development
experiences. Topics of interest include, but are not limited to, the
following areas in mobile ad hoc and sensor networks:
  ‧ Network architecture and protocols
  ‧ Software platforms and development tools
  ‧ Self-organization and synchronization
  ‧ Routing and data dissemination
  ‧ Failure resilience and fault isolation
  ‧ Energy Management
  ‧ Data, information, and signal processing
  ‧ Security and privacy
  ‧ Network planning, provisioning, and deployment
  ‧ Developments and applications
  ‧ Integration with other system

Paper submission:
MSN invites authors to submit original and unpublished work. Submissions
should include an abstract, key words, the e-mail address of the
corresponding author, and must not exceed 15 pages, including tables and
figures, with PDF, PostScript, or MSWord format.   Electronic submission
through the submission website is strongly encouraged. Submission of a paper
should be regarded as an undertaking that, should the paper be accepted, at
least one of the authors will register and attend the conference to present
the work.

Important Days:
  ‧ Submission deadline:                   30 June, 2007
  ‧ Notification of acceptance:           10 August 2007
  ‧ Final Manuscript due:                  1 September 2007 



-- 
Eric FLEURY
PROF. AT INSA of LYON
Co-HEAD OF CITI LAB & Co-Leader of ARES INRIA PROJECT
TEL: +33 472 436 421/+33 672 162 974  FAX: +33 472 436 227
WEB: http://perso.citi.insa-lyon.fr/efleury/
--------------090805080909080803080204-- --===============1169090152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1169090152==-- From manet-bounces@ietf.org Thu Jun 14 12:54:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaS-00057K-2Q; Thu, 14 Jun 2007 12:54:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HysaQ-00057F-UV for manet-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 12:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaQ-000577-KZ for manet@ietf.org; Thu, 14 Jun 2007 12:54:18 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysaQ-00067A-38 for manet@ietf.org; Thu, 14 Jun 2007 12:54:18 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.106]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HysaM-0002JN-LQ; Thu, 14 Jun 2007 12:54:15 -0400 X-MHO-User: U2FsdGVkX19HM86uQr328JD1+Xt+jVzT X-MHO-User: U2FsdGVkX1/sq82bIIgENEplPLwofluI X-MHO-User: U2FsdGVkX1+KoBiZ++ZxpsBvKy9OUvkz X-MHO-User: U2FsdGVkX1/+wI8oIXBOI0ecw2km9a7h X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+s1bhw1a2feCHCfvSr6k79 In-Reply-To: <4643AF39.9080106@nokia.com> References: <4643AF39.9080106@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Thu, 14 Jun 2007 18:53:12 +0200 To: Charles E. Perkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: Christopher Dearlove , Manet Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear Charlie, all First of all, thank you for your careful review and for your comments. See below. On 11May , 2007, at 1:48 AM, Charles E. Perkins wrote: > > Hello folks, > > Herewith, some comments on the PacketBB document. > I didn't go through the appendices yet, sigh... > > ================================================ > > Somewhere, the document should explain why the "bb". > You'll see that "bb" only appears in draft-ietf-manet-packetbb and not elsewhere. When draft-ietf-manet-packetbb is replaced by RFCXXXX, then any mention of packetbb disappears automatically ;) Let's push for quickly getting to RFCXXX ... :D > > o A message header format containing *all* necessary > information to > > allow a node to make forwarding decisions without inspecting > and > > processing the message body. Message header information > permits > > single- and multi-hop message diffusion. > > Should clarify this only affects packets with TTL > 1. > The statement is also incorrect if it is interpreted to mean > that the node's present state cannot be used in the forwarding > decision. > I think I see what you mean here. Let me first clarify that a packetbb packet may well be sent with IP- TTL=1, yet contain messages that are to be forwarded (i.e. with a message hop-limit>1). Your point is well taken that the text needs to be permissive (i.e. allow a node to not forward a packet based on present state or other criteria). We will clarify this in the I-D. > > The specification has been explicitly designed with the following > > properties in mind: > > One of the design goals ought to be compact header size, > in general -- not just for address representations. > > > Parsing logic - the regular expression specification facilitates > > generic, protocol independent, parsing logic. > > If, by putting this first, it is elevated to prime importance, > then I think the design goals have the wrong priority. These goals are actually listed in no particular order. I will clarify this in the I-D. > It should > be a goal, but considerably less important than efficiency > of representation or actual processing. Parsing is a smaller > part. I respect your opinion on this matter, as you know, and I will not dispute it. An equally correct opinion has been voiced by other parties (at least during IETF meetings, if not on the list) that parsing simplicity is a prime goal, and that the algorithmic complexity of processing a packet/message should be minimized. I am not taking a position (not in this email, at least) as to which goal is more important -- just pointing out that packetbb is designed in a space with many interested parties, and that requirements are, occasionally, seen with different importance by different parties. > > ... Full backward compatibility can be > > maintained. > > Backward compatibility to what? > Good point, that can be somewhat obscure! The idea is, that if you write DYMO code that is conformant with the DYMO specification and then -- later -- I want to add an additional bit of information (say, if a link tastes like strawberries or coffee), then I can add a "taste-TLV", which will not break your parsing of DYMO messages. Yes, I chose an absurd example here, since I'd not want to discuss the merits of a specific protocol extension, but just point out the general idea. I will clarify this in the I-D. > > Packet - the top level entity in this specification. Packets are > > transmitted over a single logical hop and are not forwarded. A > > packet contains zero or more messages, and may contain a packet > > header. > > When do we need to transmit a packet with zero messages? Assuming that you want to send just a packet TLV with, say, a packet sequence number to a neighbor node (a sort of "keep-alive-message"), then you'd want to do that without having to construct a message with a message header that you would not use. Again, you have a good point in that this should (and will) be clarified in the I-D. Will update reference & text to RFC4291 in next version of I-D. > > .......... it will employ. > > What is "it"? The "protocol"? Does it mean that the > document specifies features that may be prohibited for > use by some protocols designed according to the specification? > > Just checking! It's more benign than that. For example, OLSRv2 will state "All OLSRv2 messages use full message headers" (seq. no, ttl, hopcount, org-addr). > > = {*}? > > {*}* > > > > where is defined in Section 5.2, and is > defined > > in Section 5.4. The packet is parsed until all octets are used. > > The last sentence imposes an unnecessary restriction. > Some packets should be dropped before parsing is complete. > And, what if the packet is unparseable? > Good point, will update I-D text. > > > is an 8 bit field, specifying the type of message. A > > type with all bits cleared ('0') MUST NOT be used. > > You can just say that type 0 (zero) is RESERVED. > My reading of RESERVED is "RESERVED for future use" -- which is not the case here. It might be that I am wrong in my reading of RESERVED, however since this field MUST ABSOLUTELY NEVER be all-zeros, I prefer to write the specification to people as dumb as myself (there might be one or two out there) and be very explicit on this. > > is a 16 bit field, specifying the size of the > , > > counted in octets. > > This would be a possible use of another bit in the msg-semantics > field, which would say whether or not the msg-size were 8 or 16 bits. > It is to be hoped that most kinds packetbb messages would be usually > be less than 256 bytes long, so it would be nice if the specification > supported that case. This is a balance on if saving one octet compensates for (i) slightly more complex parsing logic and (i) using a flag out of the limited number that we have available. I am inclined to, for the next version of the I-D, to keep it as it is, and then solicit more input on this from the list and in a seperate thread. I hope that you're OK with this, knowing that your comment is not forgotten and will be discussed shortly? > > is an 8 bit field, which contains the maximum > number of > > logical hops a message should be further transmitted. > > > > is an 8 bit field, which contains the number of > logical > > hops a message has traveled. > > I can well imagine protocol messages which would not need > both of these fields. Upon reflecting on this for a while, I think that you are right. Will be updated in next version of the I-D. > This construction assumes that most address information > will be transmitted in blocks of aggregated addresses. > As we have discussed many times in the past, the value > of the given scheme is questionable if most addresses > are really singletons from an effectively flat address > space. This is the case for the overwhelming majority > of times in my experience. > > One way around this would be to have two kinds of >
s: one, as given above, and another > trivial one just consisting of the unadorned and > unpartitioned address. I will address this somewhat in another email, but just disagree in principle here: most ad hoc networks I have seen deployed, both for testing and otherwise, have had addresses assigned out of a common prefix, which lends itself to aggregation. In my opinion, having yet-another-way of representing addresses will add complexity to the specification (and to implementations of the specification). Even in the case of un-aggregatable addresses, one could collect these into one address block. So, the case that you present, and which I think is not particularly common, is fully supported. > I thought about developing a simple expression for > the overhead, depending on the expected number of > addresses that can be aggregated, but it is really > just an exercise. However, for the case of unaggregated > IPv4 addresses, the overhead from the address block > mechanism as given, is 50%. No, that would assume that you had one address-block per address, which would be inefficient. You could have simply one address block with no common head/tail and only mids (which would then be of the length of the address type). So you'd incur a fixed overhead regardless of how many addresses you add to that one address block. > > is a 16 bit field > > I hope most s will be shorter than 256 bytes, so this > Ahm, ok, it's not the length of each tlv, but of the tlv-block. I will clarify this in the I-D. > I am constantly reminded > that our results show over and over again that extra > bytes really correlate well with reduced protocol > performance, so I look for ways to make savings especially > in crucial systemic protocol elements such as this. This is probably dependent on what you have below your L3. My studies and results show, that on common L2's, sending a few extra octets does not a big change make, but making an extra transmission does. I am not sure that there are universal truths either way, though -- but it's an interesting (albeit not IETF-related) area to study. > > > Packet headers and messages can be padded to ensure 32 bit > alignment > > Packet headers and messages MAY be padded to ensure 32 bit alignment > Bingo, you're right, I'll update the I-D. > > Message type 0 MUST NOT be allocated because a zero-octet > signifies a > > packet header and zero-octets are used for padding. Message > types 1 > > to 4 are reserved because they are used by OLSR [4], which uses a > > compatible packet/message header format. > > I don't think IANA cares what type 0 signifies. Why not just > make it RESERVED? > See discussion above. I am assuming that there might be one or two individuals out there as dumb as I ;) (Feel free to disagree with me, though ;) ) > It would be better to put into the OLSR document a part > of the IANA considerations to reserve the four message > types, and delete the discussion in the PacketBB document. > Actually, these four types are those which are used in RFC3626, and since I can't update RFC3626 I think that this is the right place to put it. > Why isn't Table 7 close to the paragraph about address blocks? > Ok, I will look at if the tables in this section are close to the related text -- might be they are, or might be that I have moved text around without the associated tables in the course of editing. > >8. Security Considerations > > > ............... Since > count> and are the only fields that may be modified > when > > such a message is forwarded, this signature can be calculated > based > > Really? What about current estimates of cost, stability, delay, ...? > > Or, is this discussion only valid > "If forwarded messages are unchanged by this protocol," ? > Yes. What I mean to say is that "If the message content is immutable, only hop-count and hop-limit are changing and in that case one can...." I will clarify this in the I-D. Thanks again for your review and your comments. We'll issue an updated version of the I-D shortly, updated as indicated above and resuming discussion on the issues also indicated above in a seperate/ new thread. Looking forward to seeing you again in Chicago! Thomas -- Thomas Clausen T.Clausen@computer.org http://www.thomasclausen.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 14 12:54:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaS-00057K-2Q; Thu, 14 Jun 2007 12:54:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HysaQ-00057F-UV for manet-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 12:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaQ-000577-KZ for manet@ietf.org; Thu, 14 Jun 2007 12:54:18 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysaQ-00067A-38 for manet@ietf.org; Thu, 14 Jun 2007 12:54:18 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.106]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HysaM-0002JN-LQ; Thu, 14 Jun 2007 12:54:15 -0400 X-MHO-User: U2FsdGVkX19HM86uQr328JD1+Xt+jVzT X-MHO-User: U2FsdGVkX1/sq82bIIgENEplPLwofluI X-MHO-User: U2FsdGVkX1+KoBiZ++ZxpsBvKy9OUvkz X-MHO-User: U2FsdGVkX1/+wI8oIXBOI0ecw2km9a7h X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+s1bhw1a2feCHCfvSr6k79 In-Reply-To: <4643AF39.9080106@nokia.com> References: <4643AF39.9080106@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Thu, 14 Jun 2007 18:53:12 +0200 To: Charles E. Perkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: Christopher Dearlove , Manet Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear Charlie, all First of all, thank you for your careful review and for your comments. See below. On 11May , 2007, at 1:48 AM, Charles E. Perkins wrote: > > Hello folks, > > Herewith, some comments on the PacketBB document. > I didn't go through the appendices yet, sigh... > > ================================================ > > Somewhere, the document should explain why the "bb". > You'll see that "bb" only appears in draft-ietf-manet-packetbb and not elsewhere. When draft-ietf-manet-packetbb is replaced by RFCXXXX, then any mention of packetbb disappears automatically ;) Let's push for quickly getting to RFCXXX ... :D > > o A message header format containing *all* necessary > information to > > allow a node to make forwarding decisions without inspecting > and > > processing the message body. Message header information > permits > > single- and multi-hop message diffusion. > > Should clarify this only affects packets with TTL > 1. > The statement is also incorrect if it is interpreted to mean > that the node's present state cannot be used in the forwarding > decision. > I think I see what you mean here. Let me first clarify that a packetbb packet may well be sent with IP- TTL=1, yet contain messages that are to be forwarded (i.e. with a message hop-limit>1). Your point is well taken that the text needs to be permissive (i.e. allow a node to not forward a packet based on present state or other criteria). We will clarify this in the I-D. > > The specification has been explicitly designed with the following > > properties in mind: > > One of the design goals ought to be compact header size, > in general -- not just for address representations. > > > Parsing logic - the regular expression specification facilitates > > generic, protocol independent, parsing logic. > > If, by putting this first, it is elevated to prime importance, > then I think the design goals have the wrong priority. These goals are actually listed in no particular order. I will clarify this in the I-D. > It should > be a goal, but considerably less important than efficiency > of representation or actual processing. Parsing is a smaller > part. I respect your opinion on this matter, as you know, and I will not dispute it. An equally correct opinion has been voiced by other parties (at least during IETF meetings, if not on the list) that parsing simplicity is a prime goal, and that the algorithmic complexity of processing a packet/message should be minimized. I am not taking a position (not in this email, at least) as to which goal is more important -- just pointing out that packetbb is designed in a space with many interested parties, and that requirements are, occasionally, seen with different importance by different parties. > > ... Full backward compatibility can be > > maintained. > > Backward compatibility to what? > Good point, that can be somewhat obscure! The idea is, that if you write DYMO code that is conformant with the DYMO specification and then -- later -- I want to add an additional bit of information (say, if a link tastes like strawberries or coffee), then I can add a "taste-TLV", which will not break your parsing of DYMO messages. Yes, I chose an absurd example here, since I'd not want to discuss the merits of a specific protocol extension, but just point out the general idea. I will clarify this in the I-D. > > Packet - the top level entity in this specification. Packets are > > transmitted over a single logical hop and are not forwarded. A > > packet contains zero or more messages, and may contain a packet > > header. > > When do we need to transmit a packet with zero messages? Assuming that you want to send just a packet TLV with, say, a packet sequence number to a neighbor node (a sort of "keep-alive-message"), then you'd want to do that without having to construct a message with a message header that you would not use. Again, you have a good point in that this should (and will) be clarified in the I-D. Will update reference & text to RFC4291 in next version of I-D. > > .......... it will employ. > > What is "it"? The "protocol"? Does it mean that the > document specifies features that may be prohibited for > use by some protocols designed according to the specification? > > Just checking! It's more benign than that. For example, OLSRv2 will state "All OLSRv2 messages use full message headers" (seq. no, ttl, hopcount, org-addr). > > = {*}? > > {*}* > > > > where is defined in Section 5.2, and is > defined > > in Section 5.4. The packet is parsed until all octets are used. > > The last sentence imposes an unnecessary restriction. > Some packets should be dropped before parsing is complete. > And, what if the packet is unparseable? > Good point, will update I-D text. > > > is an 8 bit field, specifying the type of message. A > > type with all bits cleared ('0') MUST NOT be used. > > You can just say that type 0 (zero) is RESERVED. > My reading of RESERVED is "RESERVED for future use" -- which is not the case here. It might be that I am wrong in my reading of RESERVED, however since this field MUST ABSOLUTELY NEVER be all-zeros, I prefer to write the specification to people as dumb as myself (there might be one or two out there) and be very explicit on this. > > is a 16 bit field, specifying the size of the > , > > counted in octets. > > This would be a possible use of another bit in the msg-semantics > field, which would say whether or not the msg-size were 8 or 16 bits. > It is to be hoped that most kinds packetbb messages would be usually > be less than 256 bytes long, so it would be nice if the specification > supported that case. This is a balance on if saving one octet compensates for (i) slightly more complex parsing logic and (i) using a flag out of the limited number that we have available. I am inclined to, for the next version of the I-D, to keep it as it is, and then solicit more input on this from the list and in a seperate thread. I hope that you're OK with this, knowing that your comment is not forgotten and will be discussed shortly? > > is an 8 bit field, which contains the maximum > number of > > logical hops a message should be further transmitted. > > > > is an 8 bit field, which contains the number of > logical > > hops a message has traveled. > > I can well imagine protocol messages which would not need > both of these fields. Upon reflecting on this for a while, I think that you are right. Will be updated in next version of the I-D. > This construction assumes that most address information > will be transmitted in blocks of aggregated addresses. > As we have discussed many times in the past, the value > of the given scheme is questionable if most addresses > are really singletons from an effectively flat address > space. This is the case for the overwhelming majority > of times in my experience. > > One way around this would be to have two kinds of >
s: one, as given above, and another > trivial one just consisting of the unadorned and > unpartitioned address. I will address this somewhat in another email, but just disagree in principle here: most ad hoc networks I have seen deployed, both for testing and otherwise, have had addresses assigned out of a common prefix, which lends itself to aggregation. In my opinion, having yet-another-way of representing addresses will add complexity to the specification (and to implementations of the specification). Even in the case of un-aggregatable addresses, one could collect these into one address block. So, the case that you present, and which I think is not particularly common, is fully supported. > I thought about developing a simple expression for > the overhead, depending on the expected number of > addresses that can be aggregated, but it is really > just an exercise. However, for the case of unaggregated > IPv4 addresses, the overhead from the address block > mechanism as given, is 50%. No, that would assume that you had one address-block per address, which would be inefficient. You could have simply one address block with no common head/tail and only mids (which would then be of the length of the address type). So you'd incur a fixed overhead regardless of how many addresses you add to that one address block. > > is a 16 bit field > > I hope most s will be shorter than 256 bytes, so this > Ahm, ok, it's not the length of each tlv, but of the tlv-block. I will clarify this in the I-D. > I am constantly reminded > that our results show over and over again that extra > bytes really correlate well with reduced protocol > performance, so I look for ways to make savings especially > in crucial systemic protocol elements such as this. This is probably dependent on what you have below your L3. My studies and results show, that on common L2's, sending a few extra octets does not a big change make, but making an extra transmission does. I am not sure that there are universal truths either way, though -- but it's an interesting (albeit not IETF-related) area to study. > > > Packet headers and messages can be padded to ensure 32 bit > alignment > > Packet headers and messages MAY be padded to ensure 32 bit alignment > Bingo, you're right, I'll update the I-D. > > Message type 0 MUST NOT be allocated because a zero-octet > signifies a > > packet header and zero-octets are used for padding. Message > types 1 > > to 4 are reserved because they are used by OLSR [4], which uses a > > compatible packet/message header format. > > I don't think IANA cares what type 0 signifies. Why not just > make it RESERVED? > See discussion above. I am assuming that there might be one or two individuals out there as dumb as I ;) (Feel free to disagree with me, though ;) ) > It would be better to put into the OLSR document a part > of the IANA considerations to reserve the four message > types, and delete the discussion in the PacketBB document. > Actually, these four types are those which are used in RFC3626, and since I can't update RFC3626 I think that this is the right place to put it. > Why isn't Table 7 close to the paragraph about address blocks? > Ok, I will look at if the tables in this section are close to the related text -- might be they are, or might be that I have moved text around without the associated tables in the course of editing. > >8. Security Considerations > > > ............... Since > count> and are the only fields that may be modified > when > > such a message is forwarded, this signature can be calculated > based > > Really? What about current estimates of cost, stability, delay, ...? > > Or, is this discussion only valid > "If forwarded messages are unchanged by this protocol," ? > Yes. What I mean to say is that "If the message content is immutable, only hop-count and hop-limit are changing and in that case one can...." I will clarify this in the I-D. Thanks again for your review and your comments. We'll issue an updated version of the I-D shortly, updated as indicated above and resuming discussion on the issues also indicated above in a seperate/ new thread. Looking forward to seeing you again in Chicago! Thomas -- Thomas Clausen T.Clausen@computer.org http://www.thomasclausen.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 14 12:54:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaH-00052K-5F; Thu, 14 Jun 2007 12:54:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HysaG-00052E-3C for manet-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 12:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaF-000526-JL for manet@ietf.org; Thu, 14 Jun 2007 12:54:07 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysaA-000655-9p for manet@ietf.org; Thu, 14 Jun 2007 12:54:07 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.106]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hysa8-0002JN-7X; Thu, 14 Jun 2007 12:54:01 -0400 X-MHO-User: U2FsdGVkX18i2fb5UYuWHhHx1BIsn+ZX X-MHO-User: U2FsdGVkX18UGlvjZW1zpMa0nsni7K+x X-MHO-User: U2FsdGVkX1+LypBKek1fs2s+dH7YMBfE X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/amF3qKcH4Uy5kn5zuT25H In-Reply-To: <464896B2.9090309@nokia.com> References: <464896B2.9090309@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81E19688-0710-46BD-9F2D-05F7A929563D@polytechnique.fr> Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Thu, 14 Jun 2007 18:52:36 +0200 To: Charles E. Perkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "ext Dearlove, Christopher \(UK\)" , Manet Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charlie, Allow me to add a few clarifying comments below. On 14May , 2007, at 7:04 PM, Charles E. Perkins wrote: > Whether or not multiple addresses are collected is dictated by > the meaning of the message, not the desire for a person to save > space according to a parseable bucket of message fields. > I agree that when you can collect multiple addresses, the > more you can get the less percentage overhead will be > incurred for the whole collection. A message, as defined by packetbb, contains a set of addresses, with each address associated with zero or more attributes. Attributes are associated with addresses through the use of address block TLVs. There is no positional semantics of a given address being in one rather than the other address block. Let me examplify, and let's assume that addresses can be "red", "greeen" or "blue". You could then: (1) collect all red addresses in one address block, and associate an address-block TLV saying "Red" to this address block (and, obviously, the same for "Green" and "Blue", leaving you with one address block for each color) (2) collect all addresses into one or more address blocks in order to obtain the most efficient aggregation, and associate either a single multi- value address-block TLV saying "Red", "Green", and "Blue" for the appropriate addresses, or associate multiple indexed address block TLVs indicating "Red", "Green" or "Blue" as appropriate to these address blocks. Depending on how well addresses aggregate, either of these may be more efficient than the other. I think that it would be clever to pick the most efficient aggregation of addresses. But, if you would, for a specific protocol, want to collect "only RED addresses" in this address block, aggregation-efficiency be dammed, then you could of course do so. That would then, be for that protocol using packetbb to specify. In other words, addresses are collected into address blocks in order to obtain the most efficient aggregation, and are associated with attributes through TLVs -- not through being in this, that or the other address block. So, I think that I will draw the conclusion that what you are suggesting (that a protocol MAY specify that addresses to be collected into the same address block are somehow related by having common attributes) is fully supported by packetbb, as is the ability to collected into address blocks for the most efficient aggrgation fully supported by packetbb. -- Thomas Clausen T.Clausen@computer.org http://www.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 14 16:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvaA-0007Su-ST; Thu, 14 Jun 2007 16:06:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hyva9-0007KY-Ac for manet-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyva9-0007It-0Q for manet@ietf.org; Thu, 14 Jun 2007 16:06:13 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyva5-00072L-6u for manet@ietf.org; Thu, 14 Jun 2007 16:06:12 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l5EK62rw000205; Thu, 14 Jun 2007 16:06:02 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007061416060117905 ; Thu, 14 Jun 2007 16:06:01 -0400 From: "Joe Macker" To: "'Mullen, John'" , References: <20070606162620.iq4c8ltur1ck4k80@wwwstudent.murdoch.edu.au><4669398E.1030304@inria.fr><4669A835.7090004@nokia.com> <466E6802.4020906@inria.fr> <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens><466ED498.6090102@inria.fr><004c01c7ad2b$648475f0$165cfa84@SEXTANT> Subject: RE: [manet] DYMO and other routing protocols Date: Thu, 14 Jun 2007 16:05:59 -0400 Message-ID: <001801c7aebf$6cf8a6d0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcetF57/wWWtmXwKQRiJ4cNmt5n3iQABf6xgAAEeABAABAKHoABi8/+Q In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org This was discussed so you could search the archive to see more. I was going to raise the CDS issue but this was made in a previous 2003 thread. ----snippet----------- RFC 2328 also allows implicit ACKs, so this also would not require an extension. But there is still the question of whether implicit ACKs should be used on manet interfaces. It probably wouldn't hurt, but it wouldn't help much either, since only a small percentage of nodes will forward LSAs (e.g., CDS nodes or MPRs). >-----Original Message----- >From: Mullen, John [mailto:jomullen@ad.nmsu.edu]=20 >Sent: Tuesday, June 12, 2007 4:47 PM >To: manet@ietf.org >Subject: RE: [manet] DYMO and other routing protocols > >Hi Joe, =20 > >That's interesting. One approach I've seen is implicit ACKs.=20 >If A sends to B and then hears B retransmitting the update, A=20 >knows B got it. ACKs would only be needed in a few cases. For=20 >example, if B would not normally retransmit the update or if A=20 >specifically requested an ACK.=20 > >Did the analysis consider that mechanism as well? > >John P. Mullen, Ph.D. >(505) 646-2958 >jomullen@nmsu.edu >=20 >-----Original Message----- >From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] >Sent: Tuesday, June 12, 2007 1:54 PM >To: Mullen, John; manet@ietf.org >Subject: RE: [manet] DYMO and other routing protocols > >Some 2 cents. > > > >Also John, since you mentioned the ACK control tradeoff issue,=20 >if you are interested the IETF MANET-OSPF design team did some=20 >evaluation on examining tradeoffs between ACK-based control=20 >and best effort control propagation. > >-Joe >>-----Original Message----- >>From: Mullen, John [mailto:jomullen@ad.nmsu.edu] >>Sent: Tuesday, June 12, 2007 2:31 PM >>To: manet@ietf.org >>Subject: RE: [manet] DYMO and other routing protocols >> >>Agreed Philippe, >> >>My computations were greatly simplified. However, there is always a=20 >>finite probability of error and it sounds like fisheye in OLSRD takes=20 >>this into account. However, this is my concern. >> >>I work with MANETs that support critical operations, e.g., military,=20 >>disaster relief, fire fighting, etc. In these applications, the node=20 >>distribution can be very uneven and quite dynamic, due to operational=20 >>needs. For example, firefighters will place themselves along the=20 >>perimeter of a forest fire and tend to work in uneven terrain. Hence,=20 >>routes are likely to have little redundancy and even a small=20 >amount of=20 >>movement could require a change, say if a node drops below a=20 >ridge. As=20 >>a result, an error is more likely to manifest itself. In addition,=20 >>there are people at risk and a loss of communications could have=20 >>serious consequences. My feeling is that an acceptable MANET routing=20 >>protocol needs to be robust enough that such errors do not cause an=20 >>unnecessary failure. >>In addition, it is possible that such nets will become=20 >partitioned from=20 >>time to time, so the protocol needs to be able to rejoin partitioned=20 >>nets quickly. I think this is harder if a global link state=20 >approach is=20 >>taken than if the long haul is reactive. >> >>Bye for now, >> >>John P. Mullen, Ph.D. >>(505) 646-2958 >>jomullen@nmsu.edu >>=20 >>-----Original Message----- >>From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] >>Sent: Tuesday, June 12, 2007 11:15 AM >>To: Mullen, John >>Cc: manet@ietf.org >>Subject: Re: [manet] DYMO and other routing protocols >> >>You are right that the information about a local link will have an=20 >>increasing probability to be wrong when the distance=20 >increases. Not as=20 >>dramatic as you suggest (because the number of path for the=20 >TC to reach=20 >>a remote node also increases with distance and may correct=20 >the one path=20 >>failure probability). In this case a node database will give you a=20 >>"fisheye" view of the network: locally precise, more fuzzy at long=20 >>distance. The impact is not dramatic because the route starting from=20 >>far >> takes the good direction and details about the local wrong=20 >links are=20 >>resolved at the end. The path is thus very close to optimal. >> >>For this, you must activate the fisheye option, introduced by=20 >Gerla of=20 >>UCLA and included in OLSR long time ago. This allows to deal=20 >with large=20 >>network (with lot of hops and lot of nodes). The principle is=20 >that TCs=20 >>with large TTL are transmitted less frequently but with=20 >larger time to=20 >>live (otherwise remote nodes will timeout link set before a new TC=20 >>arrive). Other advantage: the control overhead is reduced and scales=20 >>better. >> >>This is included in the basic OLSRD codes and is used in practical=20 >>implementation. >> >>Philippe >> >>Mullen, John a =E9crit : >>> Good points! >>>=20 >>> If that were not enough, it is the nature of wireless >>communications that any transmission attempt may fail on a "working"=20 >>link or be successful on a "non-working" one. >>Because there is always a finite probability of success on all links,=20 >>one cannot be entirely sure which nodes actually get each updates,=20 >>assuming they are sent UDP. If you use ACKs, on the other hand, there=20 >>is the problem of deciding which node(s) decide when each update is=20 >>complete and how that knowledge is made known to the network. >>>=20 >>> I think this problem is manageable in a small, local net, >>but I'm not aware of a solution that is scalable to a MANET=20 >containing=20 >>routes of four or more links. Between random variations in received=20 >>signal strength due to fading and shadowing, local interference,=20 >>overflowing buffers, and who knows what, the chances of every update=20 >>reaching all nodes in a geographically large MANET are very small.=20 >>Thus, it would be unlikely that all nodes would have the same=20 >image of=20 >>the topology, meaning their tables would be inconsistent with each=20 >>other and at odds with the real link states. For that reason, any=20 >>proactive protocol needs to acknowledge that each node's tables are=20 >>estimates of the actual link states and must be robust enough to deal=20 >>with incomplete information. >>>=20 >>> This is one reason I think a hybrid approach would be >>advisable. Nodes in a one-, or maybe two-hop neighborhood could=20 >>exchange link data frequently, e.g., by Hello messages, and=20 >would have=20 >>a good chance of having locally consistent link state data. These=20 >>tables could provide stable data as a basis for long-haul routes,=20 >>improving the chances of a good route, and accomplish local repair.=20 >>However, the overhead for informing an entire large MANET would be=20 >>considerable. Aside from the larger number of links to=20 >update, because=20 >>probability of end-to-end success decreases with the number of hops,=20 >>all other things being equal, updates for distant nodes would have to=20 >>be either ACKed or transmitted multiple times in order to=20 >have the same=20 >>assurance that link data is correct globally as it would be locally. >>>=20 >>> To illustrate. >>>=20 >>> Suppose the probability of successful reception on a single hop is >>> 0.98 (Don't we wish!) and our standard is Pr(successful updates) = >=3D=20 >>> 0.95. Then, >>>=20 >>> # hops Pr(sucess in one try) minimum # tries for=20 >>Pr(sucess) >=3D 0.95 >>>=20 >>> 1 0.980 0.77 -> 1 >>> 2 0.960 0.93 -> 1 >>> 3 0.941 1.06 -> 2 >>> 4 0.922 1.17 -> 2 >>> 5 0.904 1.28 -> 2 =20 >>>=20 >>> The actual degradation will depend on the actual >>probabilities, which can be expected to differ by link and=20 >change over=20 >>time, but the principal will remain the same. More distant nodes will=20 >>have a greater chance of not receiving updates. To compensate, one=20 >>would either have to send multiple copies of the update or use ACKs. >>>=20 >>> Node density also plays a role. If a node has four one-hop >>neighbors and the probability of success on each link is 0.98, the=20 >>probability that all four of its neighbors receiving a single UDP=20 >>update is only 0.92. If we modify the standard to require that the=20 >>probability of all nodes receiving the update be at least=20 >0.95, now one=20 >>needs two transmissions of each update just to meet the=20 >standard in the=20 >>one-hop neighborhood. >>Going further not only increases the number of hops, but also the=20 >>number of nodes, so at some point, the overhead would become=20 >>impractically high. Additionally, sending multiple copies of=20 >an update=20 >>or using ACKs will increase the average time to propagate the=20 >updates,=20 >>which will increase the risk that the update itself is actually no=20 >>longer valid. And that is just to be 95% sure that all nodes have=20 >>current data. There is still a 5% chance that any random node=20 >will have=20 >>invalid data. >>>=20 >>> The number of updates also affects the situation. Suppose >>there are ten updates a minute, each containing only the changed=20 >>information, not the complete set of MANET link states, and the=20 >>probability that each update is successful is 0.95. The probability=20 >>that all nodes will have correct data from all ten of the=20 >changes that=20 >>occurred in that one minute, after enough time has passed to=20 >propagate=20 >>the updates, is only about 0.6. >>>=20 >>> Although the actual numbers may differ, there will always be >>some probability of failure on an attempt on any link, so there will=20 >>always be a sizable chance that any random node will have incorrect=20 >>link state data. Reducing the maximum probability of invalid data=20 >>increases the difficulty of meeting that standard exponentially.=20 >>Reducing it to zero is impossible. >>>=20 >>> Bottom line: To be successful in a wireless MANET, the >>routing protocol needs to live with the fact that any tabled=20 >>information may not be current and have mechanisms to deal with that=20 >>possibility. >>>=20 >>> John P. Mullen, Ph.D. >>> (505) 646-2958 >>> jomullen@nmsu.edu >>> =20 >>> -----Original Message----- >>> From: Herbert Rubens [mailto:hrubens@persistentsystems.com] >>> Sent: Tuesday, June 12, 2007 6:54 AM >>> To: 'Philippe Jacquet'; 'Charles E. Perkins' >>> Cc: manet@ietf.org; manet-dt@ietf.org >>> Subject: RE: [manet] DYMO and other routing protocols >>>=20 >>> Philippe, >>>=20 >>> Correct me if I am wrong, but Link-State protocols >>(e.g. OLSR) are >>> generally not 'instantaneously loop free'. Meaning if a link metric=20 >>> changes or a link goes from working to not working, the link-state=20 >>> database is not loop free until an update is received by all >>of the nodes in the network. >>> Consider a simple example: if data is flowing along a path >>and a node >>> along the path decides that the next-hop link is no longer >>working. If it removes >>> the link from the data-base and re-computes the path,=20 >>the route might be >>> back to the node that sent it the packet. Until that node >>receives an >>> update you will have a loop in the network. >>>=20 >>> It appears that when a link fails on an active >>link-state path, you >>> technically can't be routing reliably without a flood >>propagating the >>> entire network. In an on-demand (dymo, aodv, dsr) protocol, when a=20 >>> link fails on an active path you also need to propagate a >>flood to the >>> entire network before the routing can continue. So while link-state=20 >>> protocols actively track every imaginable path, it's not clear that=20 >>> they actually perform differently in the link-failure case >>that you suggested. >>>=20 >>> -Herb >>>=20 >>> -----Original Message----- >>> From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] >>> Sent: Tuesday, June 12, 2007 5:32 AM >>> To: Charles E. Perkins >>> Cc: manet@ietf.org; manet-dt@ietf.org >>> Subject: Re: [manet] DYMO and other routing protocols >>>=20 >>> Dear Charlie, >>>=20 >>> Sorry to have been kind of elliptic in my previous post. I >>didn't want >>> to mystify you;-) >>>=20 >>> In proactive protocols, when a link fails the alternative route is=20 >>> immediately available, because it is already stored in the database. >>> This what I call space diversity or space discrimination.=20 >>The quantity >>> of information needed to this space diversity is controled >>by several >>> algorithms, the MPRs in OLSR is one example. This what I >>tried to name >>> space adaptability. >>>=20 >>> In DYMO when a route fails, a new route is created with a >>new sequence >>> number. The two routes don't exist simultaneously and it >>takes time to >>> recover. This is what I tried to name time discremination. >>>=20 >>> But I don't see time adaptability in DYMO. For example if a route=20 >>> discovery fails it takes time to initiate a new route >>discovery. This >>> time should be controlled. Longer routes will have larger route=20 >>> discovery delays, therefore need larger waiting time.=20 >However longer=20 >>> route may have larger RREQ/RREP failure, therefore >>experience multiple >>> discovery route. In this case the waiting time should also >>be smaller >>> in order to minimize the delay to support multiple route=20 >discoveries. >>> Shorter waiting time may create broacast congestion and failure on=20 >>> other routes which is a killing situation. Here, serious time=20 >>> adaptability is missing. The exponential backoff won't help. >>>=20 >>> The case with unidirectional links is a straightforward example.=20 >>> Assume a node C with a strong transmission power and all=20 >other nodes=20 >>> with lower power. Node C is on the path between a node A and >>a node B.=20 >>> Assume that node C has, say, 10 unidirectional neighbors on >>that path >>> toward B. The first RREQ from A to B will go through C and=20 >via these=20 >>> neighbors and in return the RREP will fail on one of these >>neighbors.=20 >>> The later will list node C in its blacklist. After an >>initial waiting >>> time, node A will issue a new RREQ and the RREP will in >>return go via >>> another unidirectional neighor (since the first blacklisted >>link is denied): >>> therefore a second blacklisted link. And so forth until all=20 >>> unidirectional links have been blacklisted one by one: 10 route=20 >>> discoveries attempt. Applying binary exponential backoff, you will=20 >>> experience a delay larger than 1,000 times the initial route >>discovery >>> interval time. >>>=20 >>> If meanwhile one of the unidirectional neighbor un-blacklist >>its links >>> (this the only way to check if the link is now symmetric), then the=20 >>> route discovery process may never end nor succeed. The blacklist=20 >>> period (not specified in the draft) should be longer than the route=20 >>> discovery delay. >>>=20 >>> It seems that DYMO shows some fragility with respect to timers. I=20 >>> think it would be good to specify at least some strong adaptability=20 >>> algorithms to correct this. I don't think you need to pickup from=20 >>> proactive protocols for this end. >>>=20 >>> Below some links to real experiments where problems with >>recovery time >>> occurred. >>>=20 >>>=20 >>> http://www.reseaucitoyen.be/wiki/index.php/ExperiencesAODV >>> http://www.seattlewireless.net/OpenWrt >>>=20 >>>=20 >>>=20 >>> Charles E. Perkins a =E9crit : >>>> Hello Philippe, >>>> >>>> I really want to understand your point, but I confess that I am=20 >>>> somewhat mystified and not yet getting it. >>>> >>>> How does OLSR adapt to "space"? Do you mean Euclidean space with=20 >>>> constant radio range? I can just see the point about topology=20 >>>> (because of MPRs), but I think we should insist that both DYMO and=20 >>>> OLSR be equally able to utilize some SMF (or, lately for=20 >us, SMURF)=20 >>>> ways of flooding over reduced relay sets. >>>> >>>> As I understand this, the common dependence on a reduced relay set=20 >>>> will give both proactive and reactive approaches equal=20 >adaptability=20 >>>> to topology. But this still doesn't enlighten me about >>adaptability >>>> in space. >>>> >>>> Regarding the adaptability in time... >>>> >>>> DYMO has the following time-based dependencies >>>> - route timeouts >>>> - shifting route discovery anywhere up to and >>>> including application launch >>>> - some second order effects about sequence >>>> numbers. >>>> I can definitely see a role for a new extension which=20 >enables nodes=20 >>>> in a path to specify a non-default value for the route >>timeout. But >>>> it is not clear to me that this is what you are referring >>to. Could >>>> you be a bit more explicit? >>>> >>>> Anyway, this note is a long way of asking for more details, and I=20 >>>> hope you won't mind having a longer discussion about it. >>>> >>>> Finally, if you would care to point out cases where DYMO performs=20 >>>> poorly, but which are not able to be explained by reliance on=20 >>>> brute-force flooding, it would be appreciated. I know >>about the case >>>> of fully-connected traffic patterns, and a few other corner cases,=20 >>>> but somehow I feel you may have something else in mind. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> ext Philippe Jacquet wrote: >>>>> I would say that from a very broad perspective, on-demand >>protocols >>>>> discriminate routes with respect to time and proactive protocols=20 >>>>> discriminate routes with respect to space. Personnally I have=20 >>>>> preference to proactive approach because it is richer and gives=20 >>>>> better internet legacy. Objectively the two approaches have their=20 >>>>> advantages and drawbacks and the two should be considered. >>>>> >>>>> This said, I don't think that on-demand and proactive >>approaches are >>>>> represented at the same level in MANET. OLSRv2 has "space" >>>>> adaptability: i.e algorithms which automatically adapt to >>space and >>>>> topology variety, including for instance the MPR >>mechanism. In DYMO >>>>> I don't see an equivalent "time" adaptibility that goes=20 >beyond the=20 >>>>> default values in timers. I think this may explain why the >>protocol >>>>> performs great in some scenario and very poorly in other. >>>>> >>>>> Some adaptability feature in DYMO would be welcome, not >>necessarily >>>>> proactive, but at least some memory based feature could help. >>>>> >>>>> Philippe >>>>> >>>>> David Murray a =E9crit : >>>>>> Hi, >>>>>> >>>>>> I am wondering how DYMO fits in with the other routing >>protocols. I >>>>>> have read a number of papers that discuss how on-demand routing=20 >>>>>> protocols like DSR/AODV work better in highly mobile=20 >environments=20 >>>>>> where movement is fast, CPU and memory are low and batteries are=20 >>>>>> limited. Equally, in situations where movement is very low, and=20 >>>>>> there are no power limitations, protocols like >>OLSR/TBRPF/STAR perform better. >>>>>> >>>>>> So, I have a mental picture of OLSR/TBRPF being >>predominantly used >>>>>> in stationary 802.11 mesh devices and AODV/DYMO being used to=20 >>>>>> connect users mobile devices ush as phones and PDAs. Is this=20 >>>>>> correct or are things not quite as simple as this? (I >>know RFC 2501 >>>>>> discusses MANET applications and characteristics but the >>discussion >>>>>> is quite general) >>>>>> >>>>>> If this is correct, it seems to me that DYMO and AODV=20 >are used in=20 >>>>>> very similar situations (the ad hoc interconnect between users=20 >>>>>> devices). I am aware that DYMO is a simplified version of >>AODV both >>>>>> in code and network operation. It seems like the major=20 >difference=20 >>>>>> is the path accumulation feature in DYMO which allows nodes to=20 >>>>>> append their information to a RREP to give other nodes better=20 >>>>>> knowledge of the topology. It also seems that the hello >>feature has >>>>>> been removed in DYMO. So, is DYMO likely to be a replacement for=20 >>>>>> AODV or do they have different uses/applications? >>>>>> >>>>>> Thanks for your time >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/manet >>>> >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 15 13:23:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFWQ-0000Uf-7D; Fri, 15 Jun 2007 13:23:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HzFWO-0000Ua-OO for manet-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 13:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFWO-0000US-Ek for manet@ietf.org; Fri, 15 Jun 2007 13:23:40 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzFWN-0001Dn-Ob for manet@ietf.org; Fri, 15 Jun 2007 13:23:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5FHNYsD029596; Fri, 15 Jun 2007 20:23:37 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 20:23:35 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 12:23:32 -0500 Received: from [10.243.7.87] ([10.243.7.87]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 12:23:31 -0500 Message-ID: <4672CB10.9050404@nokia.com> Date: Fri, 15 Jun 2007 10:23:28 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Thomas Clausen References: <4643AF39.9080106@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 17:23:31.0895 (UTC) FILETIME=[E571BC70:01C7AF71] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Manet Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Thomas, ext Thomas Clausen wrote: > >> It should >> be a goal, but considerably less important than efficiency >> of representation or actual processing. Parsing is a smaller >> part. > > I respect your opinion on this matter, as you know, and I will not > dispute it. An equally correct opinion has been voiced by other > parties (at least during IETF meetings, if not on the list) that > parsing simplicity is a prime goal, and that the algorithmic > complexity of processing a packet/message should be minimized. Packet size matters a lot more for wireless devices than for classical IETF devices. It seems to me that one aspect of the evolving IETF engineering discipline has been to emphasize simplicity at the expense of packet size. Thus, I am not at all surprised that a large IETF constituency would carry this design philosophy over into [manet]. But if there are going to be billions of power-constrained devices, the design space changes. If you elevate simplicity to primary importance, then I think you should put a sentence into an Applicability Section that says something like: "This protocol is not intended for power-constrained devices" I think it would be more accurate. Otherwise, I think you should be willing to consider some small suggestions for power savings. > > > >> > is an 8 bit field, specifying the type of message. A >> > type with all bits cleared ('0') MUST NOT be used. >> >> You can just say that type 0 (zero) is RESERVED. >> > > My reading of RESERVED is "RESERVED for future use" -- which is not > the case here. It might be that I am wrong in my reading of RESERVED, > however since this field MUST ABSOLUTELY NEVER be all-zeros, I prefer > to write the specification to people as dumb as myself (there might be > one or two out there) and be very explicit on this My feeling is that such restrictions belong in the IANA considerations. > >> > is a 16 bit field, specifying the size of the , >> > counted in octets. >> >> This would be a possible use of another bit in the msg-semantics >> field, which would say whether or not the msg-size were 8 or 16 bits. >> It is to be hoped that most kinds packetbb messages would be usually >> be less than 256 bytes long, so it would be nice if the specification >> supported that case. > > This is a balance on if saving one octet compensates for (i) slightly > more complex parsing logic and (i) using a flag out of the limited > number that we have available. I am inclined to, for the next version > of the I-D, to keep it as it is, and then solicit more input on this > from the list and in a seperate thread. > > I hope that you're OK with this, knowing that your comment is not > forgotten and will be discussed shortly? I guess it means that I have to be on my toes to not miss the discussion. I've missed a lot of them over the last year, and I still have to review NHDP, sigh... > > >> This construction assumes that most address information >> will be transmitted in blocks of aggregated addresses. >> As we have discussed many times in the past, the value >> of the given scheme is questionable if most addresses >> are really singletons from an effectively flat address >> space. This is the case for the overwhelming majority >> of times in my experience. >> >> One way around this would be to have two kinds of >>
s: one, as given above, and another >> trivial one just consisting of the unadorned and >> unpartitioned address. > > I will address this somewhat in another email, but just disagree in > principle here: most ad hoc networks I have seen deployed, both for > testing and otherwise, have had addresses assigned out of a common > prefix, which lends itself to aggregation. Well, that is perfectly understandable. > > In my opinion, having yet-another-way of representing addresses will > add complexity to the specification (and to implementations of the > specification). Even in the case of un-aggregatable addresses, one > could collect these into one address block. So, the case that you > present, and which I think is not particularly common, is fully supported. I didn't say it was unsupported. I meant to say it was extra baggage when I want to be traveling light. > > >> I thought about developing a simple expression for >> the overhead, depending on the expected number of >> addresses that can be aggregated, but it is really >> just an exercise. However, for the case of unaggregated >> IPv4 addresses, the overhead from the address block >> mechanism as given, is 50%. > > No, that would assume that you had one address-block per address, > which would be inefficient. It darned sure is. > You could have simply one address block with no common head/tail and > only mids (which would then be of the length of the address type). So > you'd incur a fixed overhead regardless of how many addresses you add > to that one address block. But then you have to mangle the semantics of your message type to induce substructure on the address block. If you will make the statement in your draft that address blocks are encouraged to have substructure in order to satisfy any required semantics depending on message type, then we'll be done :-). > > >> I am constantly reminded >> that our results show over and over again that extra >> bytes really correlate well with reduced protocol >> performance, so I look for ways to make savings especially >> in crucial systemic protocol elements such as this. > > This is probably dependent on what you have below your L3. My studies > and results show, that on common L2's, sending a few extra octets does > not a big change make, but making an extra transmission does. I am not > sure that there are universal truths either way, though -- but it's an > interesting (albeit not IETF-related) area to study. I agree that extra messages are a lot worse than extra octets in the message. But, a few pounds on holidays, a few pounds at the company picnic, a few pounds on vacation, and pretty soon you are fat. > > > >> > Message type 0 MUST NOT be allocated because a zero-octet >> signifies a >> > packet header and zero-octets are used for padding. Message types 1 >> > to 4 are reserved because they are used by OLSR [4], which uses a >> > compatible packet/message header format. >> >> I don't think IANA cares what type 0 signifies. Why not just >> make it RESERVED? >> > > See discussion above. I am assuming that there might be one or two > individuals out there as dumb as I ;) (Feel free to disagree with me, > though ;) ) You already know I don't think you are dumb at all. > >> It would be better to put into the OLSR document a part >> of the IANA considerations to reserve the four message >> types, and delete the discussion in the PacketBB document. >> > > Actually, these four types are those which are used in RFC3626, and > since I can't update RFC3626 I think that this is the right place to > put it. I definitely do not think that there should be any normative dependency on OLSR. Since OLSRv2 will be published before any other document that might conflict with the allocations of message types, there would be no problem because OLSRv2 can insure compatibility. Certainly we can guarantee that DYMO won't cause problems here... Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 15 22:47:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOK4-0001jV-EQ; Fri, 15 Jun 2007 22:47:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HzOK1-0001jP-Uk for manet-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 22:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOK1-0001jH-Kt for manet@ietf.org; Fri, 15 Jun 2007 22:47:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzOK0-0006sU-VE for manet@ietf.org; Fri, 15 Jun 2007 22:47:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2007 19:47:28 -0700 X-IronPort-AV: i="4.16,428,1175497200"; d="scan'208"; a="166289217:sNHT64163115" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5G2lS1G001562; Fri, 15 Jun 2007 19:47:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5G2lNtX012950; Sat, 16 Jun 2007 02:47:27 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 19:47:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: Comments about draft-ietf-manet-packetbb-04 Date: Fri, 15 Jun 2007 19:48:14 -0700 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A0275A50F@xmb-sjc-219.amer.cisco.com> In-Reply-To: <4672CB10.9050404@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: Comments about draft-ietf-manet-packetbb-04 Thread-Index: AcevcfM3YhYP6xgLTRq+kGDN3SFhLgATIyZw From: "Krishna Sankar \(ksankar\)" To: "Charles E. Perkins" , "ext Thomas Clausen" X-OriginalArrivalTime: 16 Jun 2007 02:47:24.0284 (UTC) FILETIME=[AB1E9BC0:01C7AFC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9941; t=1181962048; x=1182826048; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ksankar@cisco.com; z=From:=20=22Krishna=20Sankar=20\(ksankar\)=22=20 |Subject:=20RE=3A=20[manet]=20Re=3A=20Comments=20about=20draft-ietf-manet -packetbb-04 |Sender:=20; bh=tsHNXKOc/5sjyUzjViBDW7MLhoU17saQKzWZUThrn5c=; b=r4jY8nToPCwtGPjsS1+iObFy4JtlfjJFBVqfHIB4sta8D40ORismkfbCSNhWnUP+FS52ygMm mBn4RAuS5yWNDLUKDI0xqdpvmAGf0zk7UgEu2KQ4/noMIuJgKtWz6f4ub1qrLV86Y0iRHc12en rxi5j762o/le35ayGHyoPXGwM=; Authentication-Results: sj-dkim-1; header.From=ksankar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Supporting Charles' POV, from my (very limited) experience in the sensor world, one reason packet size matters is because trx & rcv takes most of the power. I assume it is similar in the Wi-Fi and WiMax world. Moreover, in many cases the trx-rcv function is done while the system is in sleep mode (e.g. OLPC). Especially in the case of MANET, the packets go thru multiple devices, thus making small packet size more efficient (resource-wise) across the network.=20 In short, while the algorithmic complexity of processing a packet/message will only be incurred by one node, packet size will affect multiple nodes. Assuming packet routing only requires minimal classification and of course, the routing complexities which would relatively be independent of packet size, both of which I think are fair assumptions.=20 But I do want to point out the difference between complexity of packet _processing_ vs. complexity of packet _classification_ for routing. For example if we make the packet classification more complex (say by compression et al) then we do not gain much in terms of resource-efficiency.=20 Cheers > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com]=20 > Sent: Friday, June 15, 2007 10:23 AM > To: ext Thomas Clausen > Cc: Manet > Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 >=20 >=20 > Hello Thomas, >=20 > ext Thomas Clausen wrote: > > > >> It should > >> be a goal, but considerably less important than efficiency of=20 > >> representation or actual processing. Parsing is a smaller part. > > > > I respect your opinion on this matter, as you know, and I will not=20 > > dispute it. An equally correct opinion has been voiced by other=20 > > parties (at least during IETF meetings, if not on the list) that=20 > > parsing simplicity is a prime goal, and that the algorithmic=20 > > complexity of processing a packet/message should be minimized. >=20 > Packet size matters a lot more for wireless devices than for=20 > classical IETF devices. It seems to me that one aspect of=20 > the evolving IETF engineering discipline has been to=20 > emphasize simplicity at the expense of packet size. Thus, I=20 > am not at all surprised that a large IETF constituency would=20 > carry this design philosophy over into [manet]. >=20 > But if there are going to be billions of power-constrained=20 > devices, the design space changes. If you elevate simplicity=20 > to primary importance, then I think you should put a sentence=20 > into an Applicability Section that says something > like: > "This protocol is not intended for power-constrained devices" > I think it would be more accurate. >=20 > Otherwise, I think you should be willing to consider some=20 > small suggestions for power savings. >=20 > > > > > > > >> > is an 8 bit field, specifying the type of=20 > message. A > >> > type with all bits cleared ('0') MUST NOT be used. > >> > >> You can just say that type 0 (zero) is RESERVED. > >> > > > > My reading of RESERVED is "RESERVED for future use" -- which is not=20 > > the case here. It might be that I am wrong in my reading of=20 > RESERVED,=20 > > however since this field MUST ABSOLUTELY NEVER be=20 > all-zeros, I prefer=20 > > to write the specification to people as dumb as myself=20 > (there might be=20 > > one or two out there) and be very explicit on this >=20 > =20 > My feeling is that such restrictions belong in the IANA=20 > considerations. >=20 > > > >> > is a 16 bit field, specifying the size of=20 > the , > >> > counted in octets. > >> > >> This would be a possible use of another bit in the msg-semantics=20 > >> field, which would say whether or not the msg-size were 8=20 > or 16 bits. > >> It is to be hoped that most kinds packetbb messages would=20 > be usually=20 > >> be less than 256 bytes long, so it would be nice if the=20 > specification=20 > >> supported that case. > > > > This is a balance on if saving one octet compensates for=20 > (i) slightly=20 > > more complex parsing logic and (i) using a flag out of the limited=20 > > number that we have available. I am inclined to, for the=20 > next version=20 > > of the I-D, to keep it as it is, and then solicit more=20 > input on this=20 > > from the list and in a seperate thread. > > > > I hope that you're OK with this, knowing that your comment is not=20 > > forgotten and will be discussed shortly? >=20 > I guess it means that I have to be on my toes to not miss=20 > the discussion. I've missed a lot of them over the last=20 > year, and I still have to review NHDP, sigh... >=20 > > > > > >> This construction assumes that most address information will be=20 > >> transmitted in blocks of aggregated addresses. > >> As we have discussed many times in the past, the value of=20 > the given=20 > >> scheme is questionable if most addresses are really=20 > singletons from=20 > >> an effectively flat address space. This is the case for the=20 > >> overwhelming majority of times in my experience. > >> > >> One way around this would be to have two kinds of block>s:=20 > >> one, as given above, and another trivial one just=20 > consisting of the=20 > >> unadorned and unpartitioned address. > > > > I will address this somewhat in another email, but just disagree in=20 > > principle here: most ad hoc networks I have seen deployed, both for=20 > > testing and otherwise, have had addresses assigned out of a common=20 > > prefix, which lends itself to aggregation. >=20 > Well, that is perfectly understandable. >=20 > > > > In my opinion, having yet-another-way of representing=20 > addresses will=20 > > add complexity to the specification (and to implementations of the=20 > > specification). Even in the case of un-aggregatable addresses, one=20 > > could collect these into one address block. So, the case that you=20 > > present, and which I think is not particularly common, is=20 > fully supported. >=20 > I didn't say it was unsupported. I meant to say it was=20 > extra baggage when I want to be traveling light. >=20 > > > > > >> I thought about developing a simple expression for the overhead,=20 > >> depending on the expected number of addresses that can be=20 > aggregated,=20 > >> but it is really just an exercise. However, for the case of=20 > >> unaggregated > >> IPv4 addresses, the overhead from the address block mechanism as=20 > >> given, is 50%. > > > > No, that would assume that you had one address-block per address,=20 > > which would be inefficient. > It darned sure is. >=20 > > You could have simply one address block with no common=20 > head/tail and=20 > > only mids (which would then be of the length of the address=20 > type). So=20 > > you'd incur a fixed overhead regardless of how many=20 > addresses you add=20 > > to that one address block. >=20 > But then you have to mangle the semantics of your message=20 > type to induce substructure on the address block. If you=20 > will make the statement in your draft that address blocks are=20 > encouraged to have substructure in order to satisfy any=20 > required semantics depending on message type, then we'll be done :-). >=20 > > > > > >> I am constantly reminded > >> that our results show over and over again that extra bytes really=20 > >> correlate well with reduced protocol performance, so I=20 > look for ways=20 > >> to make savings especially in crucial systemic protocol=20 > elements such=20 > >> as this. > > > > This is probably dependent on what you have below your L3.=20 > My studies=20 > > and results show, that on common L2's, sending a few extra=20 > octets does=20 > > not a big change make, but making an extra transmission=20 > does. I am not=20 > > sure that there are universal truths either way, though --=20 > but it's an=20 > > interesting (albeit not IETF-related) area to study. >=20 > I agree that extra messages are a lot worse than extra=20 > octets in the message. >=20 > But, a few pounds on holidays, a few pounds at the company=20 > picnic, a few pounds on vacation, and pretty soon you are fat. >=20 > > > > > > > >> > Message type 0 MUST NOT be allocated because a zero-octet > >> signifies a > >> > packet header and zero-octets are used for padding. =20 > Message types 1 > >> > to 4 are reserved because they are used by OLSR [4],=20 > which uses a > >> > compatible packet/message header format. > >> > >> I don't think IANA cares what type 0 signifies. Why not=20 > just make it=20 > >> RESERVED? > >> > > > > See discussion above. I am assuming that there might be one or two=20 > > individuals out there as dumb as I ;) (Feel free to=20 > disagree with me,=20 > > though ;) ) > You already know I don't think you are dumb at all. >=20 > > > >> It would be better to put into the OLSR document a part of=20 > the IANA=20 > >> considerations to reserve the four message types, and delete the=20 > >> discussion in the PacketBB document. > >> > > > > Actually, these four types are those which are used in RFC3626, and=20 > > since I can't update RFC3626 I think that this is the right=20 > place to=20 > > put it. >=20 > I definitely do not think that there should be any normative=20 > dependency on OLSR. Since OLSRv2 will be published before=20 > any other document that might conflict with the allocations=20 > of message types, there would be no problem because OLSRv2=20 > can insure compatibility. Certainly we can guarantee that=20 > DYMO won't cause problems here... >=20 >=20 > Regards, > Charlie P. >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jun 16 16:30:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzeuu-0006hZ-9i; Sat, 16 Jun 2007 16:30:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hzeut-0006hT-Mq for manet-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 16:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzeut-0006hL-DP for manet@ietf.org; Sat, 16 Jun 2007 16:30:39 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzeur-0008UG-VE for manet@ietf.org; Sat, 16 Jun 2007 16:30:39 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l5GKUZYn024106; Sat, 16 Jun 2007 15:30:36 -0500 Received: from 172.147.229.244 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Sat, 16 Jun 2007 15:30:36 -0500 (CDT) Message-ID: <3426.172.147.229.244.1182025836.squirrel@webmail.jsums.edu> Date: Sat, 16 Jun 2007 15:30:36 -0500 (CDT) From: nmeghanathan@jsums.edu To: manet@ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: pdini@cisco.com Subject: [manet] ICDS 2008 || The Second International Conference on the Digital Society || February 10-15, 2008 - St. Luce, Martinique X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Please apologize for any cross-postings --------------------------------------- CALL FOR PAPERS, TUTORIALS, PANELS The Second International Conference on the Digital Society ICDS 2008 February 10-15, 2008 - St. Luce, Martinique Site: http://www.iaria.org/conferences2008/ICDS08.html Submission: http://www.iaria.org/conferences2008/SubmitICDS08.html Important deadlines: Submission deadline: September 5, 2007 Notification of acceptance: October 15, 2007 Registration/camera ready: November 5, 2007 ICDS 2008 Tracks (details in the CfP on site) * Disruptive and enabling technologies * Internet * eCommerce * Consumer-oriented devices and services * Intelligent computation * Networking and telecommunications * Economics of security and protection * System advanced paradigms * Management and control * Digital analysis and processing * Mobile devices and biotechnologies * Software robustness for digital society * Consumer-oriented digital economics * Government services in the context of digital society * ICT support for collaboration * Information and knowledge management (eknow) * Telemedicine and eHealth (telemed) ================================ Publicity Board _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 18 05:05:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DB2-0000e6-EO; Mon, 18 Jun 2007 05:05:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0DB0-0000dE-O4 for manet-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:05:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0DB0-0000d5-EN for manet@ietf.org; Mon, 18 Jun 2007 05:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0D7j-0008WK-U6 for manet@ietf.org; Mon, 18 Jun 2007 05:02:11 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0D3M-0007Wn-Vq for manet@ietf.org; Mon, 18 Jun 2007 04:57:42 -0400 Received: by an-out-0708.google.com with SMTP id c17so347742anc for ; Mon, 18 Jun 2007 01:57:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=my0kJYN3ut05e+VaPK4dJzyqHRwpX1f2EA9d+5HhcIlxdYj+uajAZjwleC0k692bXTfdmkl31bw/GeO2pRfxHA+/XOqdAXYka0CASAnkWMIjgHZrlSkZKFyWbTQ4sotQr/bz6/bCMN/Rfu/jqHmi2Wd1YKWJzJ9oB9mM6gSQ4Wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YT+ekoRqycABnToJwX3rJzdFxm84ylQGfJAjOjpqx/b7f76RR8x87JaVlZZAUsJ2+0noH7MxcIiIrmfMmPr8wJozYO8F5r3LwBwlaKxILXMYUiF/L5u8BWnjKYcOGN933K7xswaCXVxu+P7VbAyFVxEjgybG7a/GnYSk2BtMwzw= Received: by 10.100.111.16 with SMTP id j16mr2457824anc.1182157060752; Mon, 18 Jun 2007 01:57:40 -0700 (PDT) Received: by 10.100.120.15 with HTTP; Mon, 18 Jun 2007 01:57:40 -0700 (PDT) Message-ID: Date: Mon, 18 Jun 2007 14:27:40 +0530 From: "chayanika sengupta" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-TMDA-Confirmed: Mon, 18 Jun 2007 05:05:34 -0400 Subject: [manet] code of LAR sceme2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0281458498==" Errors-To: manet-bounces@ietf.org --===============0281458498== Content-Type: multipart/alternative; boundary="----=_Part_71139_22934785.1182157060734" ------=_Part_71139_22934785.1182157060734 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I want to implement a new routing protocol in NS2 for which i will be needing code of LAR scheme2 against which i will compare my protocol. can anyone please send me or state the site for the code of LAR sceme2.Please HELP. Chayanika. ------=_Part_71139_22934785.1182157060734 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I want to implement a new routing protocol in NS2 for which i will be needing code of LAR scheme2 against which i will compare my protocol.
can anyone please send me or state the site for the code of LAR sceme2.Please HELP.
Chayanika.
------=_Part_71139_22934785.1182157060734-- --===============0281458498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0281458498==-- From manet-bounces@ietf.org Mon Jun 18 11:35:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JFv-00061w-6T; Mon, 18 Jun 2007 11:35:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0JFu-00061r-EQ for manet-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JFu-00061j-4c for manet@ietf.org; Mon, 18 Jun 2007 11:35:02 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0JFt-0005JM-Fl for manet@ietf.org; Mon, 18 Jun 2007 11:35:02 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1182180900!14093548!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 3620 invoked from network); 18 Jun 2007 15:35:00 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-128.messagelabs.com with SMTP; 18 Jun 2007 15:35:00 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l5IFZ0wv024427 for ; Mon, 18 Jun 2007 08:35:00 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5IFYxNG027095 for ; Mon, 18 Jun 2007 10:34:59 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5IFYvZd027059 for ; Mon, 18 Jun 2007 10:34:58 -0500 (CDT) Message-ID: <4676A620.2070707@gmail.com> Date: Mon, 18 Jun 2007 17:34:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000749-2, 16/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Subject: [manet] OLSRv2 and DYMO for MANEMO Egress-Egress X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello MANETers, I'm still in the process of identifying how the two MANET routing protocols OLSRv2 and DYMO could be used in the MANEMO topology egress-egress. I'm writing a section for a certain MANEMO draft about this. However, I have much difficulty in matching the two protocols precisely on the MANEMO egress-egress topoology. The problems I have are mostly that when I read the MANET documents I tend to make remarks to MANET WG about the inner coherency of the two MANET protocols, and forget the goal to match them on the MANEMO E-E topology :-) I realize though that when I make these remarks on MANET I'm not well understood: people may not appreciate when I write too many questions or when I complain too much about something MANET - sorry about that. Thus I think I decided to post only once the entire the set of questions I have on the MANET list, embedded in the text of MANEMO, and see whether anyone can help describe how OLSRv2 and DYMO could accomodate the E-E topology. Thanks for any answer you may have for the embedded questions. Alex ------------------------------------------------------------------------ 5. MANET protocols for MANEMO E-E Basic Topology In this section we describe the use of two MANET routing protocols for the Egress-Egress MANEMO topology. It is important to identify the issues with protocol behaviour in order to either suggest improvements to MANET protocols or to motivate the design of alternative mechanisms. There's no selective intention of declaring a MANEMO winning protocol among the two MANET protocols considered. MANET Working Group is currently specifying two routing protocols which are particularly adapted to the E-E MANEMO topology: Optimized Link-State Routing protocol (OLSRv2 []) and Dynamic MANET On-demand (DYMO) Routing []). The two protocols fit largely within at least three conceptual distinctive classifications: 'pro-active' vs. 'on-demand', 'reactive' vs. 'table-driven' and 'link-state' vs 'distance-vector' respectively. For example DYMO is known as a on-demand table-driven distance-vector protocol whereas OLSRv2 the others. In the E-E basic topology it is assumed that two moving networks are deployed in two vehicles respectively. The two moving networks have an IP prefix (MNP) assigned to the hosts (LFN). Each moving network is not pre-configured with the IP address of the egress interface or the MNP of the other router; however, applications on LFN1 know the IP address of LFN2 either by static configuration or by dynamic acquisition from DNS. While the two networks can be pre-configured locally with IPsec keys and certificats, a network has no knowledge of another network's IPsec key. Once the two vehicles are in radio range the hosts of each vehicle need to communicate directly. The discussion is limited to IPv6 only, not IPv4. LL1 and LL2 are the IPv6 link-local addresses of the two egress interfaces of Mobile Routers MR1 and MR2. For LFN1 connections to the IP address of LFN2 to be succesful there is a need for each MR to (securely) learn the IP address of the other MR and to (securely) distribute the MNPs among the two routers. +-----+ |LFN1 | +--+--+ e+-----+i | LL1 +--| MR1 |------+--- | +-----+ 1::/64 (MNP) | | e+-----+i 2::/64 (MNP) LL2 +--| MR2 |------+--- +-----+ | +--+--+ |LFN2 | +-----+ For each MANET protocol we try to identify: -is a router periodically sending out route messages? are messages sent in response to solicitations? -are default routes being taken into account? -what are the MANET protocol message contents? -how are the neighbor's IP addresses learned? -can a router initiate a route discovery process on behalf of a host attached to it? -what are the security aspects taken into account by the respective protocol (are keys assumed as pre-shared? are certs used? is IPsec recommended? arelink/app-layer security tools recommended instead of network-layer? are new security mechanisms developped?)? 5.1 DYMO and E-E Basic Topology The main contribution of DYMO to routing technology is the 'on-demand' building of routes; this means that the establishment of application data flows between two end nodes (e.g. TCP three-way handshake) is preceded by eventual IP route message exchange and creation of routing table entries at intermediary routers. Current routing technology is actually not trying to build routes when application data packets have no route to follow - these packets are simply dropped (and eventually ICMP Destination Unreachable is sent.) The protocol consists of three UDP messages: Route Request, Route Response and Route Error (RREQ, RREP and RERR), sent to a link-local scoped multicast address. Sequence numbers are used for avoiding routing loops. Routes in the routing table have timers associated such that routes exist only during a certain lifetime. MR1 MR2 | | |--MLD-REPORT->| +-----+ |<-MLD-REPORT--| |LFN1 | | | +--+--+ |-----RREQ---->| e+-----+i | |<----RREP-----| LL1 +--| MR1 |------+--- | | | +-----+ 1::/64 |<----RREQ-----| | |-----RREP---->| | e+-----+i 2::/64 LL2 +--| MR2 |------+--- +-----+ | MR1 MR2 +--+--+ | | |LFN2 | |--MLD-REPORT->| +-----+ |<-MLD-REPORT--| | | |-----RREP---->| |<----RREP-----| -is a router periodically sending out route messages? are messages sent in response to solicitations? Behaviour is as follows: periodically send RREQ and thus receive RREP; or periodically advertise RREP. -are default routes being taken into account? "If a default route exists in the forwarding table, and the router were not configured to do anything special based on the information in the packet (e.g. src/dst, etc), the packet could be forwarded without performing route discovery." -what are the MANET protocol message contents? RREQ followed by RREP: the RREQ should contain nothing; the RREP should contain the MNP and the src link-layer address. Periodic RREP: should contain the MNP and the src link-layer address. The hoplimit should be 1. -how are the neighbor's IP addresses learned? How? -can a router initiate a route discovery process on behalf of a host attached to it? "DYMO specifies that the Mobile Router should build routes when it receives LFNs application data for which it has no routes. " -what are the security aspects taken into account by the respective protocol (are keys assumed as pre-shared? are certs used? is IPsec recommended? are link/app-layer security tools recommended instead of network-layer? are new security mechanisms developped?)? The DYMO document demands the use of Authentication Header for RREQ, RREP and RERR messages. However, the document does not describe in detail the position of the AH header for IPv4 and IPv6 cases (can it be simply deduced?). Also the protocol does not describe the necessity of Encapsulating Security Payload, nor the dynamic use of keys for IPsec purposes (DYMO assumes keys are shared among all MANET members). Additional DYMO question: what is the 'distance-vector' in this E-E case? 5.2 OLSRv2 and E-E Basic Topology The main contribution of OLSRv2 to routing technology is the establishment of partially valid routes and the use of multi-point relays (MPRs). This means that... The OLSRv2 protocol consists of two UDP messages: HELLO and TC (Traffic Control) transmitted periodically. There is no request/response semantics (messages are not sent in response to a request, they're only advertised periodically and unsolicited). MR1 MR2 | | |--MLD-REPORT->| +-----+ |<-MLD-REPORT--| |LFN1 | | | +--+--+ |-----TC------>| e+-----+i | |<----TC-------| LL1 +--| MR1 |------+--- | +-----+ 1::/64 | | e+-----+i 2::/64 LL2 +--| MR2 |------+--- +-----+ | MR1 MR2 +--+--+ | | |LFN2 | |--MLD-REPORT->| +-----+ |<-MLD-REPORT--| | | |-----HELLO--->| |<----HELLO----| -is a router periodically sending out route messages? are messages sent in response to solicitations? Periodically send TC or periodically send HELLO; no means to have solicited responses. -are default routes being taken into account? No. -what are the MANET protocol message contents? TC: should contain the MNP and the src link-layer address. Can it? HELLO: it should contain the MNP and the src link-layer address. Can it? The hoplimit should be 1. -how are the neighbor's IP addresses learned? Don't know. -can a router initiate a route discovery process on behalf of a host attached to it? Don't know. -what are the security aspects taken into account by the respective protocol (are keys assumed as pre-shared? are certs used? is IPsec recommended? arelink/app-layer security tools recommended instead of network-layer? are new security mechanisms developped?)? The OLSRv2 document (Appendix G) assumes keys are pre-shared among MANET members. It also recommends the use of application-level security (such as pgp ; the document also lets think that link-layer security should be used (instead of explicitely recommending network-layer security); document recommends IPsec AH and sometimes a digital signature sent as a separate OLSRv2 TLV TC message. Additional OLSRv2 question: what is the 'link-state' in the E-E case? what is the MPR? 5.3 Acknowledgements Several aspects exposed in this section have been discussed publicly or privately with Charles Perkins, Ben McCarthy, Ryuji Wakikawa, Pascal Thubert, Thomas Clausen, Ian Chakeres and Teco Boot. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 18 13:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0LCL-0006sg-Tn; Mon, 18 Jun 2007 13:39:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0LCK-0006sb-Jz for manet-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0LCK-0006sS-AS for manet@ietf.org; Mon, 18 Jun 2007 13:39:28 -0400 Received: from cse-mail.unl.edu ([129.93.165.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0LCF-0000m4-Te for manet@ietf.org; Mon, 18 Jun 2007 13:39:28 -0400 Received: from netlab.unl.edu (netlab.unl.edu [129.93.165.30]) by cse-mail.unl.edu (8.13.6/8.13.5) with ESMTP id l5IHdIEC005856 for ; Mon, 18 Jun 2007 12:39:23 -0500 (CDT) Received: from netlab.unl.edu (localhost [127.0.0.1]) by netlab.unl.edu (8.13.8+Sun/8.12.10) with ESMTP id l5IHdIZT029909 for ; Mon, 18 Jun 2007 12:39:18 -0500 (CDT) Received: (from byrav@localhost) by netlab.unl.edu (8.13.8+Sun/8.12.10/Submit) id l5IHdIsm029908 for manet@ietf.org; Mon, 18 Jun 2007 12:39:18 -0500 (CDT) X-Authentication-Warning: netlab.unl.edu: byrav set sender to byrav@cse.unl.edu using -f Date: Mon, 18 Jun 2007 12:39:18 -0500 From: Byrav Ramamurthy To: manet Message-ID: <20070618173918.GA29900@cse.unl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (cse-mail.unl.edu [129.93.165.11]); Mon, 18 Jun 2007 12:39:23 -0500 (CDT) X-Virus-Scanned: ClamAV 0.90.3/3454/Mon Jun 18 01:25:23 2007 on cse-mail.unl.edu X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [manet] CFP: IEEE INFOCOM 2008 (Paper registration deadline just 1 week away!) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org (Our apologies if you receive duplicate messages.) ========================================================================== CALL FOR PAPERS The 27th Annual Conference of the IEEE Communications Society IEEE INFOCOM 2008 Sponsored by IEEE Communications Society April 13-19, 2008 Phoenix, Arizona, USA Conference URL: http://www.ieee-infocom.org/2008/ EDAS URL: http://www.edas.info/newPaper.php?c=5065& Author Guidelines: http://cse.unl.edu/~byrav/INFOCOM2008/author-instructions.html ========================================================================== Important Dates: ================ Registration due: June 25, 2007, 11:59 PM PDT (required) Full paper due: July 2, 2007, 11:59 PM PDT (firm) Notification of acceptance November 12, 2007 Final version due January 15, 2008 Specialized Workshops April 13, 18, 2008 Conference Sessions April 15-17, 2008 Mini-conference April 14, 2008 Topics of Interest: =================== The IEEE INFOCOM 2008 conference seeks papers describing significant research contributions to the field of computer and data communication networks. We invite submissions on network architecture, design, implementation, operations, analysis, measurement, performance, and simulation. Topics of interest include, but are not limited to, the following: * Ad hoc mobile networks * Addressing & location management * Broadband access technologies * Capacity planning * Cellular & broadband wireless nets * Congestion control * Content distribution * Cross layer design and optimization * Cyber-physical computing/networking * Denial of service * Delay/disruption tolerant networks * Future Internet design * Implementation & experimental testbeds * Middleware support for networking * Mobility models & systems * Multicast & anycast * Multimedia protocols and networking * Network applications & services * Network architectures * Network control * Network management * Network simulation and emulation * Novel network architectures * Optical networks * Peer-to-peer communications * Performance evaluation * Power control and management * Pricing & billing * Resource allocation & management * Routing protocols * Scheduling & buffer management * Security, trust, & privacy * Self-organizing networks * Sensor nets & embedded systems * Service overlays * Switches & switching * Topology characterization & inference * Traffic measurement and analysis * Traffic engineering, & control * Virtual & overlay networks * Web services & performance * Wireless mesh networks and protocols Submission: =========== Authors should prepare a Portable Document Format (PDF) version of their full paper. Papers must be no longer than NINE (9) pages, in font size no smaller than 10 points, and must fit properly on US "Letter"-sized paper (8.5 x 11 inches). Submission and formatting instructions are available at: http://cse.unl.edu/~byrav/INFOCOM2008/author-instructions.html The deadline for registering the TITLE and the ABSTRACT of the paper with the EDAS electronic submission system is June 25, 2007, 11:59PM PDT and the deadline for submitting the complete PAPER is July 2, 2007, 11:59 PM PDT. See the above websites for detailed formatting and submission instructions. In the event that a paper cannot be included in the main conference program, authors may be invited to submit an abbreviated version (5 pages) of the paper to be considered for inclusion in the IEEE INFOCOM 2008 mini-conference. Organizing Committee: ===================== General Chair: Douglas Merrill, Google, USA General Vice-Chair: Debanjan Saha, IBM T. J. Watson Research Center, USA Technical Program Co-Chairs: Jennifer C. Hou, University of Illinois at Urbana Champaign, USA Shivkumar Kalyanaraman, Rensselaer Polytechnic Institute, USA Krishna Sivalingam, University of Maryland, Baltimore County, USA EDAS Chair: Byrav Ramamurthy, University of Nebraska-Lincoln, USA Mini-conference Co-chairs: K.K. Ramakrishnan, AT&T Labs Research, USA Byrav Ramamurthy, University of Nebraska-Lincoln, USA Publication Co-chairs: Sergey Gorinsky, Washington University in Saint Louis, USA Chonggang Wang, University of Arkansas, USA Panel Co-chairs: Guoliang (Larry) Xue, Arizona State University, USA Junshan Zhang, Arizona State University, USA Workshop Co-chairs: Ehab Al-Shaer, DePaul University, USA Mohamed Eltoweissy, Virginia Tech, USA Poster Co-chairs: Qian Zhang, Hong Kong University of Science and Technology, China Xi Zhang, Texas A&M University, USA Student Activities Chair: Chunming Qiao, SUNY at Buffalo, USA Student Travel Grants Co-chairs: Vinod Vokkarane, University of Massachusetts, Dartmouth, USA Hongyi Wu, University of Louisiana, USA TPC Meeting Arrangements Co-Chairs: Suresh Subramaniam, George Washington University, USA Susan Cheng, George Washington University, USA Infrastructure Chair: Peter Baker, Google, USA Public Relations Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada Local Activities Chair: Korianne Cremona, Google, USA Local Arrangements Chair: Naomi Devlin, Google, USA Standing Committee Chair: Harvey Freeman, HAF Consulting, Inc., USA ========================================================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 18 13:48:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0LKu-0000cT-98; Mon, 18 Jun 2007 13:48:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0LKr-0000cN-At for manet-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0LKr-0000cE-1T for manet@ietf.org; Mon, 18 Jun 2007 13:48:17 -0400 Received: from smtp.rennes.supelec.fr ([193.54.192.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0LKp-0004Hm-MY for manet@ietf.org; Mon, 18 Jun 2007 13:48:17 -0400 Received: from arkoon.ssir.rennes.supelec.fr (smtp.rennes.supelec.fr [127.0.0.1]) by smtp.rennes.supelec.fr (8.13.1/8.13.1) with ESMTP id l5IHxsJt023220 for ; Mon, 18 Jun 2007 19:59:54 +0200 Received: (from uucp@localhost) by arkoon.ssir.rennes.supelec.fr id l5IHmEnt014133 for ; Mon, 18 Jun 2007 19:48:14 +0200 Received: from A by B ; Mon, 18 Jun 2007 17:48:09 +0000 Received: from A by B ; Mon, 18 Jun 2007 19:50:17 +0200 (CEST) Message-ID: <4676C55C.2060100@rennes.supelec.fr> Date: Mon, 18 Jun 2007 19:48:12 +0200 From: Adnane asmaa User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [manet] measurements of the performances of protocol OLSR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello all, i am working on trust properties in OLSR, simulations are done with glomosim,i found many researchs about OLSR simulation with glomosim or NS-2. but i need informations about experimentation and performance of OLSR in a real ad hoc network, ???? Regards Asmaa _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 18 16:08:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NWF-0000Us-3L; Mon, 18 Jun 2007 16:08:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0NWC-0000TK-P6 for manet-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 16:08:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NFB-0006We-Nj; Mon, 18 Jun 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0NFA-0004iv-CN; Mon, 18 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4F9CE175B3; Mon, 18 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0NEg-00087c-2P; Mon, 18 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-05.txt Pages : 40 Date : 2007-6-18 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-18125453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-18125453.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Tue Jun 19 00:26:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VIE-0006Dq-Vu; Tue, 19 Jun 2007 00:26:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0VIE-0006Dl-2e for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 00:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VID-0006Dd-OS for manet@ietf.org; Tue, 19 Jun 2007 00:26:13 -0400 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav03.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VI9-0005Ki-Mv for manet@ietf.org; Tue, 19 Jun 2007 00:26:13 -0400 Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F17A72908A2 for ; Tue, 19 Jun 2007 13:26:07 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id E72512906F4 for ; Tue, 19 Jun 2007 13:26:07 +0900 (JST) Received: (qmail 11349 invoked from network); 19 Jun 2007 13:26:07 +0900 Received: from unknown (HELO ms01.net.ie.niigata-u.ac.jp) (133.35.156.1) by mxav03.cc.niigata-u.ac.jp with SMTP; 19 Jun 2007 13:26:07 +0900 Received: from [172.23.150.106] (ms02.net.ie.niigata-u.ac.jp [133.35.156.2]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 4E75C11DF5 for ; Tue, 19 Jun 2007 13:26:04 +0900 (JST) Message-ID: <46775AF5.8090205@net.ie.niigata-u.ac.jp> Date: Tue, 19 Jun 2007 13:26:29 +0900 From: =?ISO-2022-JP?B?GyRCNmI8dzh3GyhC?= User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [manet] question about qualnet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to know what is difference between phy802.11b rx-model and ber-based rx-model in the qualnet. in the phy802.11b model how to calculate sinr and ber? regards Jin Shouguang _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 04:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZQO-00023I-6Q; Tue, 19 Jun 2007 04:50:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0ZQN-00023B-1i for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 04:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZQM-000233-O1 for manet@ietf.org; Tue, 19 Jun 2007 04:50:54 -0400 Received: from mail.gdatech.co.in ([202.144.30.226] helo=gdatech.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZQL-0000KT-71 for manet@ietf.org; Tue, 19 Jun 2007 04:50:54 -0400 Received: from [192.168.0.2] (localhost.localdomain [127.0.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 265F587809D for ; Tue, 19 Jun 2007 01:50:51 -0700 (PDT) X-Propel-Return-Path: Received: from gdatech.co.in ([192.168.0.3]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.0.6841-branch_6613 $Rev: 6586 $) id gP3jr76j8OP0; Tue, 19 Jun 2007 01:50:51 -0700 Received: from mail.gdatech.co.in (unknown [192.168.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id E3A55878076 for ; Tue, 19 Jun 2007 01:50:50 -0700 (PDT) Received: (qmail 18493 invoked by uid 89); 19 Jun 2007 09:02:15 -0000 Received: from unknown (HELO ?192.168.3.90?) (b.nagarajan@192.168.3.90) by 0 with SMTP; 19 Jun 2007 09:02:15 -0000 Message-ID: <46779902.4030105@gdatech.co.in> Date: Tue, 19 Jun 2007 14:21:14 +0530 From: nagarajan User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: manet X-Propel-ID: gP3jr76j8OP0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [manet] Topology tuple in OLSR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0553002791==" Errors-To: manet-bounces@ietf.org --===============0553002791== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

       In RFC 3626 OLSR, it is given that each destination in the network maintains at least one "Topology Tuple". I would like to know how many  "Topology Tuples" can be maintained by a node?? or The maximum number of "Topology Tuples" that a node is allowed to maintain??

Looking forward your reply

Thanks and regards,
Nagarajan
--===============0553002791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0553002791==-- From manet-bounces@ietf.org Tue Jun 19 06:55:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0bMz-000883-8F; Tue, 19 Jun 2007 06:55:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0bMx-00087y-Hj for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 06:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0bMx-00087q-8H for manet@ietf.org; Tue, 19 Jun 2007 06:55:31 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0bMw-0004L2-TP for manet@ietf.org; Tue, 19 Jun 2007 06:55:31 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1182250529!1913776!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 9179 invoked from network); 19 Jun 2007 10:55:29 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-11.tower-153.messagelabs.com with SMTP; 19 Jun 2007 10:55:29 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5JAtTQV009380 for ; Tue, 19 Jun 2007 05:55:29 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JAtSsQ003628 for ; Tue, 19 Jun 2007 05:55:29 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JAtQ86003551 for ; Tue, 19 Jun 2007 05:55:27 -0500 (CDT) Message-ID: <4677B619.2040804@gmail.com> Date: Tue, 19 Jun 2007 12:55:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [manet] Three issues with PacketBB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Three issues with PacketBB as specified in draft-ietf-manet-packetbb-05. >
is defined by: > > = > > ? > ? > ? > ? > * I find it unnecessarily complex to represent two addresses by encoding only once their common most significant bits ('head') and followed by the differentiating 'tail'. This representation proposes to encode two addresses 1.1.1.1 and 1.2.2.2 as a unique head '1' and two tails '1.1.1' and '2.2.2'. Two 'head-len' and 'tail-len' fields are used. I think there is little gain in memory space when encoding this way as opposed to if we encoded fully 1.1.1.1 and 2.2.2.2. I think it is indeed a more intelligent way of encoding a common head but there's probably little gain in memory space (because headlen and taillen should be encoded too). > if present is an 8 bit field, which contains the total > length (in octets) of the head of all of the addresses. I think this is an error; the length of the common 'head' part of two addresses (most significant bits) should be counted in bits not bytes. IPv4 CIDR does so and in IPv6 it is so too. This error can be seen in action at least in the DYMO spec where the length of the head part of an IPv4 address is specified as 3 octets whereas it should be 24bits. Thus DYMO can't represent an IPv6 prefix length of eg 26bits (it's not a multiple of 8). My personal oppinion is to encode fully both addresses. > is omitted if mid-length == 0, otherwise each is a field > of length mid-length octets, representing the mid of the > corresponding address in the address block. I think 'mid' terminology can overlap the OLSRv1 'MID' term: they don't mean the same. I think neither DYMO nor OLSRv2 use the mid parts of an address, but I may be wrong. > 5.4. Padding IPv6 has a means to encode padding, rfc2460 (1 octet padding is a '0' and N octets of padding is... TLV). I think we could reuse the IPv6 mechanisms to do padding instead of a new mechanism. If we do so we may have a contention with PacketBB: if PacketBB suggests padding 3 octets to be '0', '0', '0', IPv6 rfc2460 suggests differently: '1', '1', '0'. Oppinions? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 07:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0biD-0005BS-2y; Tue, 19 Jun 2007 07:17:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0biB-0005BF-6Z for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 07:17:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0biA-0005B6-TB for manet@ietf.org; Tue, 19 Jun 2007 07:17:26 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0bi9-0002jl-6R for manet@ietf.org; Tue, 19 Jun 2007 07:17:26 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JBHNtw002370 for ; Tue, 19 Jun 2007 12:17:23 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JBHN9o017909 for ; Tue, 19 Jun 2007 12:17:23 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 12:17:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 12:17:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Three issues with PacketBB Date: Tue, 19 Jun 2007 12:17:23 +0100 Message-ID: In-Reply-To: <4677B619.2040804@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Three issues with PacketBB Thread-Index: AceyYGurXrkDKfrgR6mxLlFYDd7r4AAABmeQ From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "manet" X-OriginalArrivalTime: 19 Jun 2007 11:17:23.0501 (UTC) FILETIME=[68E9D5D0:01C7B263] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > This representation proposes to encode two addresses 1.1.1.1 and 1.2.2.2=20 > as a unique head '1' and two tails '1.1.1' and '2.2.2'. Two 'head-len'=20 > and 'tail-len' fields are used. > > I think there is little gain in memory space when encoding this way as > opposed to if we encoded fully 1.1.1.1 and 2.2.2.2. Assuming the latter is a typo for 1.2.2.2 then indeed there isn't much gain. But supposing it were 1.1.1.1 and 1.1.1.2? Or indeed 1.1.1.x for several different x values? And suppose it were IPv6 rather than IPv4? (And IPv6 is the reason for common tail compression.) >> if present is an 8 bit field, which contains the total >> length (in octets) of the head of all of the addresses. > I think this is an error; the length of the common 'head' part of two=20 > addresses (most significant bits) should be counted in bits not bytes. > IPv4 CIDR does so and in IPv6 it is so too. No, it's not an error, it's deliberate. packetbb is octet based. Trying to make it non-octet based really does add to the complexity for a trivial gain at best. Given that this is purely about whether the addresses have a common part, not any functional meaning, if you have 26 common bits, then just treat it as 24, the fact that the next 2 bits happen to be the same is unimportant, they are repreated in each mid. Now should you record 24 or 3? The latter is more efficient and avoids issues like "but what if you send 26?". > This error can be seen in action at least in the DYMO spec where the=20 > length of the head part of an IPv4 address is specified as 3 octets=20 > whereas it should be 24bits. Thus DYMO can't represent an IPv6 prefix > length of eg 26bits (it's not a multiple of 8). It's still not an error, because prefix lengths are represented by a TLV, where you do specify it in bits. > My personal oppinion is to encode fully both addresses. This is the packetbb tradeoff (or one of them) complexity versus efficiency. Your preference is for lower complexity, lower efficiency. Other people want both higher. (Well, they want efficiency higher, the cost is higher complexity.) We've chosen what we think is a reasonable compromise. Incidentally there's nothing in packetbb that insists you actually compress addresses efficiently. You can set both head and tail lengths to zero and send addresses uncompressed. But you'll need to be able to handle received compressed addresses. >> is omitted if mid-length =3D=3D 0, otherwise each is a field >> of length mid-length octets, representing the mid of the >> corresponding address in the address block. > I think 'mid' terminology can overlap the OLSRv1 'MID' term: they don't=20 > mean the same. They have nothing to do with each other. But that's all right, OLSRv1 doesn't use packetbb, and OLSRv2 doesn't use MID messages. So there's no confusion at all. > I think neither DYMO nor OLSRv2 use the mid parts of an address, but I > may be wrong. I'm not sure what you mean here. In the example you gave above, 1.1.1.1 and 1.2.2.2, the last 24 bits are the "mid" part - the tail is empty (zerotail is set). OLSRv2 and DYMO may send or receive addresses like this. >> 5.4. Padding > > IPv6 has a means to encode padding, rfc2460 (1 octet padding is a '0'=20 > and N octets of padding is... TLV). I think we could reuse the IPv6=20 > mechanisms to do padding instead of a new mechanism. If we do so we may=20 > have a contention with PacketBB: if PacketBB suggests padding 3 octets > to be '0', '0', '0', IPv6 rfc2460 suggests differently: '1', '1', '0'. The RFC2460 padding (as you report it, I'm not familiar with the details) won't work here - padding is optional in packetbb. (Actually I'd be happy to remove it altogether, but someone wanted it.) All zero padding works very simply - after the end of a packet header or message just discard all zero octets (because there is no message type zero - which we need in order to have the option of a packet headerless packet). I see no point in trying for spurious compatibility with RFC2460. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 08:43:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d30-0006A1-Op; Tue, 19 Jun 2007 08:43:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0d2y-00069t-V0 for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 08:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d2y-00069f-LE for manet@ietf.org; Tue, 19 Jun 2007 08:43:00 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0d2y-0005Vl-3l for manet@ietf.org; Tue, 19 Jun 2007 08:43:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1182256978!14175935!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21604 invoked from network); 19 Jun 2007 12:42:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 19 Jun 2007 12:42:58 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JCgw09029514; Tue, 19 Jun 2007 05:42:58 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5JCgvLM009831; Tue, 19 Jun 2007 07:42:57 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5JCgsUj009764; Tue, 19 Jun 2007 07:42:55 -0500 (CDT) Message-ID: <4677CF49.2000409@gmail.com> Date: Tue, 19 Jun 2007 14:42:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Three issues with PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Christopher, Dearlove, Christopher (UK) wrote: > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> This representation proposes to encode two addresses 1.1.1.1 and >> 1.2.2.2 as a unique head '1' and two tails '1.1.1' and '2.2.2'. Two >> 'head-len' and 'tail-len' fields are used. >> >> I think there is little gain in memory space when encoding this way >> as opposed to if we encoded fully 1.1.1.1 and 2.2.2.2. > > Assuming the latter is a typo for 1.2.2.2 then indeed there isn't > much gain. But supposing it were 1.1.1.1 and 1.1.1.2? Or indeed > 1.1.1.x for several different x values? And suppose it were IPv6 > rather than IPv4? (And IPv6 is the reason for common tail > compression.) (yes typo I meant 1.2.2.2 not 2.2.2.2). Indeed memory space gains of using head-tail compared to full encoding can vary. >>> if present is an 8 bit field, which contains the >>> total length (in octets) of the head of all of the addresses. > >> I think this is an error; the length of the common 'head' part of >> two addresses (most significant bits) should be counted in bits not >> bytes. > >> IPv4 CIDR does so and in IPv6 it is so too. > > No, it's not an error, it's deliberate. packetbb is octet based. > Trying to make it non-octet based really does add to the complexity > for a trivial gain at best. Given that this is purely about whether > the addresses have a common part, not any functional meaning, if you > have 26 common bits, then just treat it as 24, the fact that the > next 2 bits happen to be the same is unimportant, they are repreated > in each mid. I meant the value contained by the 2bits between 24 and 26 are _not_ the same. > Now should you record 24 or 3? The latter is more efficient and > avoids issues like "but what if you send 26?". I think we don't understand each other. I don't see how is it possible to disambiguate two addresses represented as head-tail if we don't precisely encode the headlength. Receiver simply can't decode correctly a field saying 3octets when sender meant 26bits. >> This error can be seen in action at least in the DYMO spec where >> the length of the head part of an IPv4 address is specified as 3 >> octets whereas it should be 24bits. Thus DYMO can't represent an >> IPv6 prefix >> >> length of eg 26bits (it's not a multiple of 8). > > It's still not an error, because prefix lengths are represented by a > TLV, where you do specify it in bits. Ok - I don't mean prefix length. I mean to disambiguate two addresses encoded as head-tail whose headlen is only encoded as octets not bits. This means I can't encode head-tail two addresses whose most significant bits differ at a boundary different than octet - right? >> My personal oppinion is to encode fully both addresses. > > This is the packetbb tradeoff (or one of them) complexity versus > efficiency. Your preference is for lower complexity, lower > efficiency. Other people want both higher. (Well, they want > efficiency higher, the cost is higher complexity.) We've chosen what > we think is a reasonable compromise. I understand there's a trade-off. > Incidentally there's nothing in packetbb that insists you actually > compress addresses efficiently. You can set both head and tail > lengths to zero and send addresses uncompressed. But you'll need to > be able to handle received compressed addresses. Ok then. So I think my remark is then to DYMO, or the way DYMO uses PacketBB to encode messages. >>> is omitted if mid-length == 0, otherwise each is a >>> field of length mid-length octets, representing the mid of the >>> corresponding address in the address block. > >> I think 'mid' terminology can overlap the OLSRv1 'MID' term: they > don't >> mean the same. > > They have nothing to do with each other. But that's all right, OLSRv1 > doesn't use packetbb, and OLSRv2 doesn't use MID messages. So > there's no confusion at all. Ok, so OLSRv2 does _not_ use MID messages but can use mid encoding. >> I think neither DYMO nor OLSRv2 use the mid parts of an address, >> but I may be wrong. > > I'm not sure what you mean here. In the example you gave above, > 1.1.1.1 and 1.2.2.2, the last 24 bits are the "mid" part - the tail > is empty (zerotail is set). OLSRv2 and DYMO may send or receive > addresses like this. In the example given by DYMO document the encoding is not as you say. The address semantics is 1bit (you seem to say it's three). I am not sure whether this is a remark for PacketBB authors to simplify PacketBB or to DYMO authors to use it correctly. But certainly it's an incoherence between PacketBB and DYMO. PacketBB: > = ? ? > ? ? * > > is an 8 bit field specifying the interpretation of > the remainder of the address block: > > bit 0 (nohead): if cleared ('0'), then is included in > , and may be included in . If > set ('1'), then and are not included in > . > > bit 1 (notail) and bit 2 (zerotail): MUST NOT both be set ('1'). > Otherwise, they are interpreted according to Table 1. > > bits 3-7: are RESERVED and MUST each be cleared ('0') to be in > accordance with this version of the specification. DYMO example: > Message Body - Address Block > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Number Addrs=2 |0|HeadLength=3 | Head : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : > (cont) | Target.Tail | Orig.Tail | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also please allow me to question the necessity of the 'mid' part of an address. Why is it necessary to encode an address in a message as a threefold head-mid-tail? Isn't it sufficient to encode an address as address-and-eventually-prefix-length? Is there another (non-MANET) protocol using addresses as threefold split entities? >>> 5.4. Padding >> >> IPv6 has a means to encode padding, rfc2460 (1 octet padding is a >> '0' and N octets of padding is... TLV). I think we could reuse the >> IPv6 mechanisms to do padding instead of a new mechanism. If we >> do so we may have a contention with PacketBB: if PacketBB suggests >> padding 3 octets to be '0', '0', '0', IPv6 rfc2460 suggests >> differently: '1', '1', '0'. > > The RFC2460 padding (as you report it, I'm not familiar with the > details) won't work here - padding is optional in packetbb. (Actually > I'd be happy to remove it altogether, but someone wanted it.) Err... I don't know. I think I like packets that are built on precisely 32bit boundaries, they are easier to grasp conceptually and to write documents about. They correspond to widely deployed computer architecture memory schemes and compilers, to standardized ntohs and htons, to int C type, etc. Then, if we accept to use only 32bit-bounded PacketBB messages then there exist widely available software libraries to use the IPv6 way of padding, no need to write new code or new parts of spec. > All zero padding works very simply - after the end of a packet header > or message just discard all zero octets (because there is no message > type zero - which we need in order to have the option of a packet > headerless packet). I see no point in trying for spurious > compatibility with RFC2460. I would find strange PacketBB to carry IPv6 addresses and not refer to rfc2460. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 09:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dRW-0004WE-W5; Tue, 19 Jun 2007 09:08:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0dRV-0004W3-MS for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dRV-0004Vl-CX for manet@ietf.org; Tue, 19 Jun 2007 09:08:21 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0dRS-0003Dw-Nk for manet@ietf.org; Tue, 19 Jun 2007 09:08:21 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1182258497!1623718!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 31049 invoked from network); 19 Jun 2007 13:08:17 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-153.messagelabs.com with SMTP; 19 Jun 2007 13:08:17 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l5JD8Hwb027039 for ; Tue, 19 Jun 2007 06:08:17 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5JD8G1Q001974 for ; Tue, 19 Jun 2007 08:08:16 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5JD8DS5001794 for ; Tue, 19 Jun 2007 08:08:14 -0500 (CDT) Message-ID: <4677D538.4040206@gmail.com> Date: Tue, 19 Jun 2007 15:08:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [manet] New definition of term 'TLV' in PacketBB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I think the term TLV (type-length-value) is overloaded by the PacketBB spec: > is defined by: > > = > > ? > ? > ? > ? In many RFCs "TLV" is used to just mean Type-Length-Value, with Type and Length represented each on one byte and the Value on Length bytes. I think when generally people talk about TLV they really mean this simplicity afforded by type-length-value as opposed to encoding additional things like semantics, index, etc. IMHO we should use TLV as simply type-length-value instead of encoding additional semantics and index. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 09:10:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dTI-0005kT-8X; Tue, 19 Jun 2007 09:10:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0dTG-0005kL-QN for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dTG-0005kD-Gw for manet@ietf.org; Tue, 19 Jun 2007 09:10:10 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0dTE-0003vg-6Q for manet@ietf.org; Tue, 19 Jun 2007 09:10:10 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1182258607!1914137!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 11171 invoked from network); 19 Jun 2007 13:10:07 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-14.tower-153.messagelabs.com with SMTP; 19 Jun 2007 13:10:07 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l5JDA6Bb016590 for ; Tue, 19 Jun 2007 06:10:06 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5JDA5iJ003969 for ; Tue, 19 Jun 2007 08:10:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5JDA3xC003791 for ; Tue, 19 Jun 2007 08:10:04 -0500 (CDT) Message-ID: <4677D5A6.2080601@gmail.com> Date: Tue, 19 Jun 2007 15:09:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] Representing addresses with PacketBB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org PacketBB can represent addresses: network addresses (IPv4 and IPv6) and other types of addresses. > An address is specified as a sequence of address-length octets of the > form head:mid:tail. An address block is an ordered set of addresses > sharing the same head and tail, and having individual mids. Network > addresses may be represented using the PREFIX_LENGTH TLV defined in > Section 6. What are the other types of addresses that PacketBB considers? Is it link-layer address like MAC defined for IEEE of 48bit length? If so, I think it should be specified so. These addresses have a precisely defined semantics, including separation in two parts (vendor and id) not three parts head-mid-tail. Are there other addresses considered by PacketBB? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 09:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dfY-0002CL-3u; Tue, 19 Jun 2007 09:22:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0dfW-0002CD-2D for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dfV-0002C5-Os for manet@ietf.org; Tue, 19 Jun 2007 09:22:49 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0dfU-0008L3-Ev for manet@ietf.org; Tue, 19 Jun 2007 09:22:49 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1182259367!1600052!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 17072 invoked from network); 19 Jun 2007 13:22:47 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-2.tower-153.messagelabs.com with SMTP; 19 Jun 2007 13:22:47 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l5JDMk0A018344 for ; Tue, 19 Jun 2007 06:22:46 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5JDMk31007728 for ; Tue, 19 Jun 2007 08:22:46 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5JDMiqP007621 for ; Tue, 19 Jun 2007 08:22:45 -0500 (CDT) Message-ID: <4677D89E.6030601@gmail.com> Date: Tue, 19 Jun 2007 15:22:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [manet] Encoding prefix length in PacketBB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > 6.1. Address Block TLV Specification > > > +----------------------+------+--------+----------------------------+ > | Name | Type | Length | Value | > +----------------------+------+--------+----------------------------+ > | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | > | | | | is a network address, | > | | | | rather than a host | > | | | | address. The value is the | > | | | | length of the | > | | | | prefix/netmask. | > +----------------------+------+--------+----------------------------+ I think the text should say that the value is the length of the prefix (or the netmask) in bits, specifically not in octets. It's not good to be silent about this, easily leads to confusions. > An address in an address block without an associated PREFIX_LENGTH > TLV may be considered to have a prefix length equal to the address > length in bits (i.e. address-length times 8). I agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 09:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dhV-0002j9-Pn; Tue, 19 Jun 2007 09:24:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0dhS-0002j3-JB for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dhS-0002iv-9g for manet@ietf.org; Tue, 19 Jun 2007 09:24:50 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dhP-0000OI-CJ for manet@ietf.org; Tue, 19 Jun 2007 09:24:49 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JDOkCL012246 for ; Tue, 19 Jun 2007 14:24:46 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JDOkon021901 for ; Tue, 19 Jun 2007 14:24:46 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 14:24:46 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:24:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Three issues with PacketBB Date: Tue, 19 Jun 2007 14:24:45 +0100 Message-ID: In-Reply-To: <4677CF49.2000409@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Three issues with PacketBB Thread-Index: Aceyb3AU0DOqZAoBSKqpDmsimEzGsQAA5a8A From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Jun 2007 13:24:45.0803 (UTC) FILETIME=[341493B0:01C7B275] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'm replying to this one, but I may cut it off then, as time presses on other things. > I think we don't understand each other. I don't see how is it possible > to disambiguate two addresses represented as head-tail if we don't > precisely encode the headlength. Receiver simply can't decode correctly=20 > a field saying 3octets when sender meant 26bits. It's really very simple. Take your example of 1.1.1.1 and 1.2.2.2. This actually has 30 common bits. But we work in common octets and it has 3. So we send (noting that the different pieces are mids, not a common tail) what reports that Head octets =3D 1 Tail octets =3D 0 (and hence mid octets =3D 3, as addres length =3D 4) Head octet 0x01 First set of mid octets 0x01 0x01 0x01 Second set of mid octets 0x02 0x02 0x02 And it's all there. > This means I can't encode head-tail two addresses whose most significant=20 > bits differ at a boundary different than octet - right? Wrong. See above. > In the example given by DYMO document the encoding is not as you say.=20 > The address semantics is 1bit (you seem to say it's three). I am not=20 > sure whether this is a remark for PacketBB authors to simplify PacketBB=20 > or to DYMO authors to use it correctly. But certainly it's an=20 > incoherence between PacketBB and DYMO. I can't remark on this aspect of DYMO, I haven't looked at it recently. Obviously if I'd noticed an issue I'd have let the DYMO authors know, so either it's not there, is there and I missed it, or has been introduced since I last looked at DYMO. No idea which. > Also please allow me to question the necessity of the 'mid' part of an > address. Two main reasons - IPv6. A node may (I understand) use a common EUI-64 identifier for more than one interface, but with different prefixes. This would correspond to have a tail length of (at least) 8 octets. - Network addresses. If I want to send e.g. 10.0.0.0/16 and 10.1.0.0/16 then I have a common head (1 octet, 10) and a common tail (2 octets, 0 and 0 - I can use the zerotail bit to avoid sending these). > I would find strange PacketBB to carry IPv6 addresses and not refer to > rfc2460. We're only dealing with addresses, so we just need to refer to IPv6 address architecture. And that's RFC 4291 (recently obsoleted RFC 3513 which we do refer to. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 09:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dmU-0002bN-9l; Tue, 19 Jun 2007 09:30:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0dmS-0002b8-UN for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dmS-0002b0-Kv for manet@ietf.org; Tue, 19 Jun 2007 09:30:00 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dmR-0001c9-9M for manet@ietf.org; Tue, 19 Jun 2007 09:30:00 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JDTv1s015259 for ; Tue, 19 Jun 2007 14:29:57 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JDTves023523 for ; Tue, 19 Jun 2007 14:29:57 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 14:29:57 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:29:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Representing addresses with PacketBB Date: Tue, 19 Jun 2007 14:29:57 +0100 Message-ID: In-Reply-To: <4677D5A6.2080601@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Representing addresses with PacketBB Thread-Index: Aceyc0imvv6fHcrfTyqY0GqYBzUVlQAAfdwA From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "manet" X-OriginalArrivalTime: 19 Jun 2007 13:29:57.0712 (UTC) FILETIME=[EDFE1D00:01C7B275] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > What are the other types of addresses that PacketBB considers? You can use it for whatever you want. Within the IETF probably only IPv4 and IPv6. But other applications are possible. > These addresses have a precisely defined semantics, But packetbb doesn't. The split is purely for compression. How we do it is informed by what sort of patterns we expect, and therefore what sort of compression may be useful. But as far as packetbb is concerned, addresses are sets of octets, that we compress, send, and uncompress at the other end. The meaning and any internal structure of those addresses is someone else's problem. If our compression happens to match the internal structure, or not, don't care. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 09:34:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dqQ-0000hP-Fi; Tue, 19 Jun 2007 09:34:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0dqO-0000hI-A1 for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dqO-0000h9-0L for manet@ietf.org; Tue, 19 Jun 2007 09:34:04 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dqM-0003I1-68 for manet@ietf.org; Tue, 19 Jun 2007 09:34:03 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JDY07U000822 for ; Tue, 19 Jun 2007 14:34:00 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JDY0H7026896 for ; Tue, 19 Jun 2007 14:34:00 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 14:34:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:34:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Tue, 19 Jun 2007 14:33:59 +0100 Message-ID: In-Reply-To: <4677D538.4040206@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New definition of term 'TLV' in PacketBB Thread-Index: AceydOuJVjXYFyWxR22LRsJXWZaroAAAQq/g From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "manet" X-OriginalArrivalTime: 19 Jun 2007 13:34:00.0309 (UTC) FILETIME=[7E977A50:01C7B276] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I think the term TLV (type-length-value) is overloaded by the PacketBB spec: There are many uses of TLV in many places. Some are simple, some are more complicated. This one does the job it's intended to do. You actually can't do that job with just a type, a length and a value as you then couldn't apply information to just some of the addresses in an address block. And that's essential. I'm afraid I don't find this particular criticism constructive, so I'm not going to discuss this point further. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 10:06:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eLu-00037W-7W; Tue, 19 Jun 2007 10:06:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0eLs-00037Q-Jw for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eLs-00037I-AD for manet@ietf.org; Tue, 19 Jun 2007 10:06:36 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0eLq-0002k8-Pp for manet@ietf.org; Tue, 19 Jun 2007 10:06:36 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1182261993!15939881!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 11033 invoked from network); 19 Jun 2007 14:06:33 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-128.messagelabs.com with SMTP; 19 Jun 2007 14:06:33 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l5JE6XFO017977; Tue, 19 Jun 2007 07:06:33 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JE6Wu8007000; Tue, 19 Jun 2007 09:06:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JE6Uba006931; Tue, 19 Jun 2007 09:06:31 -0500 (CDT) Message-ID: <4677E2E1.1080505@gmail.com> Date: Tue, 19 Jun 2007 16:06:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Three issues with PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: > I'm replying to this one, but I may cut it off then, as > time presses on other things. That's fine, thanks. I am curious to hear others' oppinions as well and or wait for your replies later. >> I think we don't understand each other. I don't see how is it >> possible >> to disambiguate two addresses represented as head-tail if we don't >> precisely encode the headlength. Receiver simply can't decode > correctly >> a field saying 3octets when sender meant 26bits. > > It's really very simple. Take your example of 1.1.1.1 and 1.2.2.2. > This actually has 30 common bits. But we work in common octets > and it has 3. > So we send (noting that the different pieces are > mids, not a common tail) what reports that > > Head octets = 1 > Tail octets = 0 > (and hence mid octets = 3, as addres length = 4) > Head octet 0x01 > First set of mid octets 0x01 0x01 0x01 > Second set of mid octets 0x02 0x02 0x02 > > And it's all there. So two IPv4 addresses differing at the seventh most significant bit will have to be encoded without a common head part - right? In this case, the spec doesn't seem to say whether a head-length is absent or present but equal to 0: > if present is an 8 bit field, which contains the total > length (in octets) of the head of all of the addresses. > > head-length is a variable, defined to equal if > present, or 0 otherwise. > > is omitted if head-length == 0, otherwise it is a field of > the head-length leftmost octets of all the addresses. It seems to say that head-length must be present and equal to 0. It would be present and adding to unnecessary overhead? >> Also please allow me to question the necessity of the 'mid' part of an >> address. > > Two main reasons > > - IPv6. A node may (I understand) use a common EUI-64 identifier for > more than one interface, but with different prefixes. This would > correspond to have a tail length of (at least) 8 octets. YEs, but this doesn't show the necessity of the third 'mid' part. There are only two parts: head and tail ('head' is first 64bits and 'tail' is the Interface ID or EUI-64). > - Network addresses. If I want to send e.g. 10.0.0.0/16 and 10.1.0.0/16 > then I have a common head (1 octet, 10) and a common tail (2 octets, > 0 and 0 - I can use the zerotail bit to avoid sending these). And 'mid'? [Generally I'm ok - I think I understand the compression effects of head-mid-tail type of encoding addresses. Maybe if more indexes (head-uppermid-lowermid-tail) are used then more compression can be achieved. But this looks so different compared to other protocols I'm used to. ROHC compresses headers not addresses - why not using ROHC?. Mobile IPv6 message encodings don't compress addresses. Bandwidth is very high on some links. Etc.] >> I would find strange PacketBB to carry IPv6 addresses and not refer to >> rfc2460. > > We're only dealing with addresses, so we just need to refer to > IPv6 address architecture. And that's RFC 4291 (recently > obsoleted RFC 3513 which we do refer to.) YEs, I agree, but there is much more here than just IPv6 address architecture once you say PacketBB packets are transported in UDP over IPv6... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 10:12:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eRG-0001M4-AL; Tue, 19 Jun 2007 10:12:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0eRF-0001Lz-Lx for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eRF-0001Lr-CO for manet@ietf.org; Tue, 19 Jun 2007 10:12:09 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0eRD-0004HB-4j for manet@ietf.org; Tue, 19 Jun 2007 10:12:09 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1182262326!30178031!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 23015 invoked from network); 19 Jun 2007 14:12:06 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-13.tower-119.messagelabs.com with SMTP; 19 Jun 2007 14:12:06 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5JEC6DH012459; Tue, 19 Jun 2007 09:12:06 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5JEC5Lu026886; Tue, 19 Jun 2007 09:12:05 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5JEC2V7026813; Tue, 19 Jun 2007 09:12:03 -0500 (CDT) Message-ID: <4677E42D.1040700@gmail.com> Date: Tue, 19 Jun 2007 16:11:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] New definition of term 'TLV' in PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> I think the term TLV (type-length-value) is overloaded by the >> PacketBB > spec: > > There are many uses of TLV in many places. Some are simple, some are > more complicated. This one does the job it's intended to do. But it's different than what rfc2460 calls a 'TLV'. > You actually can't do that job with just a type, a length and a value > as you then couldn't apply information to just some of the addresses > in an address block. And that's essential. > > I'm afraid I don't find this particular criticism constructive, so > I'm not going to discuss this point further. Ok, I again went into MANET document debugging instead of contending just reading them :-( Generally speaking, I don't think it's constructive to ignore existence of already defined TLV mechanisms, address encoding mechanisms and code availability. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 10:19:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eYZ-0004aV-GE; Tue, 19 Jun 2007 10:19:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0eYX-0004aQ-ND for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eYX-0004aI-Dl for manet@ietf.org; Tue, 19 Jun 2007 10:19:41 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eYX-0006zf-15 for manet@ietf.org; Tue, 19 Jun 2007 10:19:41 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JEJeYr015452 for ; Tue, 19 Jun 2007 15:19:40 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JEJdlc001929 for ; Tue, 19 Jun 2007 15:19:39 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 15:19:39 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:19:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Three issues with PacketBB Date: Tue, 19 Jun 2007 15:19:39 +0100 Message-ID: In-Reply-To: <4677E2E1.1080505@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Three issues with PacketBB Thread-Index: AceyeyzafSkKMwzCRbW2xJ/wT6UJbAAAYyww From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Jun 2007 14:19:39.0324 (UTC) FILETIME=[DF2BFFC0:01C7B27C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > So two IPv4 addresses differing at the seventh most significant bit will=20 > have to be encoded without a common head part - right? Right. > In this case, the spec doesn't seem to say whether a head-length is=20 > absent or present but equal to 0: >> if present is an 8 bit field, which contains the total >> length (in octets) of the head of all of the addresses. That "if present" is a pretty good hint that it doesn't have to be present. But more importantly you missed bit 0 (nohead): if cleared ('0'), then is included in , and may be included in . If set ('1'), then and are not included in . As for including a equal to zero, it's legal. Not efficient, but legal. > YEs, but this doesn't show the necessity of the third 'mid' part. There=20 > are only two parts: head and tail ('head' is first 64bits and 'tail' is=20 > the Interface ID or EUI-64). No, what I'm saying is that a node may use (using upper case letters for 64 bits and a / to join them) A/Z and B/Z as two addresses of the same interface, where Z is its EUI-64. Of course A and B may also have some head bits in common, or may not. > And 'mid'? mid is the uncompressed bit. Always is. Sometimes you have a common head. Sometimes you have a common tail. Sometimes you have both. Sometimes you have neither. mid is the bit in the middle that is different. It can have zero length but that will be (I expect) uncommon. > YEs, I agree, but there is much more here than just IPv6 address=20 > architecture once you say PacketBB packets are transported in UDP over > IPv6... But invisibly to IPv6. packetbb is just carrying the addresses. It's up to a protocol that does know something about addresses - maybe DYMO, maybe an autoconf mechanism that uses packetbb to interpret those addresses. packetbb is NOT a protocol. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 10:23:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ebr-0005RN-Gd; Tue, 19 Jun 2007 10:23:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0ebp-0005RD-Ry for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ebp-0005R5-IR for manet@ietf.org; Tue, 19 Jun 2007 10:23:05 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ebn-0007kp-89 for manet@ietf.org; Tue, 19 Jun 2007 10:23:05 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0ebm-000N7G-I9; Tue, 19 Jun 2007 10:23:02 -0400 X-MHO-User: U2FsdGVkX1/jwebFOO2q9nX4RJPDBbK9 X-MHO-User: U2FsdGVkX1+xvSp1Y8R9L3Wqeos/4eQu X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19GWjIzgW9pm0sW7asrGbr9 In-Reply-To: <4677E42D.1040700@gmail.com> References: <4677E42D.1040700@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] New definition of term 'TLV' in PacketBB Date: Tue, 19 Jun 2007 16:22:58 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Alex, I appreciate your reviewing of the MANET WG specs. Generally, I think that it might be advantageous if you try to understand WHY the specs are the way they are, rather than to launch into observing a difference with some other similar mechanism and then taking this as an indication that something is broken. TLVs, for example, are TLVs, with the addendum of specifying "to which entities they apply". This is necessary since it allows doing efficient address aggregation. The alternative -- naive TLVs without such information -- would lead to a much less efficient address aggregation. (Notice that this is a simplified description, but that it should get the point through) Since one of the MANET wg's design-dogmas is "efficient when sensible", many such trade-offs have been considered and discussed over the years, and packetbb reflects the result of a number of such discussions. Thomas On Jun 19, 2007, at 4:11 PM, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) wrote: >>> I think the term TLV (type-length-value) is overloaded by the >>> PacketBB >> spec: >> There are many uses of TLV in many places. Some are simple, some are >> more complicated. This one does the job it's intended to do. > > But it's different than what rfc2460 calls a 'TLV'. > >> You actually can't do that job with just a type, a length and a value >> as you then couldn't apply information to just some of the addresses >> in an address block. And that's essential. >> I'm afraid I don't find this particular criticism constructive, so >> I'm not going to discuss this point further. > > Ok, I again went into MANET document debugging instead of > contending just reading them :-( Generally speaking, I don't think > it's constructive to ignore existence of already defined TLV > mechanisms, address encoding mechanisms and code availability. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 10:24:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ecj-00064q-IA; Tue, 19 Jun 2007 10:24:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0ech-000614-VB for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ech-00060w-Lg for manet@ietf.org; Tue, 19 Jun 2007 10:23:59 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ecQ-0007rG-Nk for manet@ietf.org; Tue, 19 Jun 2007 10:23:59 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JENfNe001490 for ; Tue, 19 Jun 2007 15:23:41 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JENfxa003260 for ; Tue, 19 Jun 2007 15:23:41 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 15:23:41 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:23:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Tue, 19 Jun 2007 15:23:40 +0100 Message-ID: In-Reply-To: <4677E42D.1040700@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New definition of term 'TLV' in PacketBB Thread-Index: Aceye9rWi5Wh3/huSVqkkQA6pGwSEAAAQ8gw From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Jun 2007 14:23:40.0904 (UTC) FILETIME=[6F2A2E80:01C7B27D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >> There are many uses of TLV in many places. Some are simple, some are >> more complicated. This one does the job it's intended to do. > > But it's different than what rfc2460 calls a 'TLV'. So what? It's not the only non-RFC2460 TLV in the world either. > Generally speaking, I don't think it's=20 > constructive to ignore existence of already defined TLV mechanisms,=20 > address encoding mechanisms and code availability. Who says we did? In the case of TLVs, just having type, length and value was insufficient. So we added what was needed, and then added stuff to make it more efficient. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:17:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fRv-0002UT-Jp; Tue, 19 Jun 2007 11:16:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fRt-0002UH-Ud for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fRt-0002U9-L6 for manet@ietf.org; Tue, 19 Jun 2007 11:16:53 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0fRs-0006gX-KV for manet@ietf.org; Tue, 19 Jun 2007 11:16:53 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1182266211!7664702!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22193 invoked from network); 19 Jun 2007 15:16:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 19 Jun 2007 15:16:51 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JFGprZ018658; Tue, 19 Jun 2007 08:16:51 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5JFGoUJ020251; Tue, 19 Jun 2007 10:16:50 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5JFGmbl020142; Tue, 19 Jun 2007 10:16:48 -0500 (CDT) Message-ID: <4677F35A.4030906@gmail.com> Date: Tue, 19 Jun 2007 17:16:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Three issues with PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> So two IPv4 addresses differing at the seventh most significant bit >> will >> have to be encoded without a common head part - right? > > Right. > >> In this case, the spec doesn't seem to say whether a head-length is >> absent or present but equal to 0: >>> if present is an 8 bit field, which contains the > total >>> length (in octets) of the head of all of the addresses. > > That "if present" is a pretty good hint that it doesn't have to > be present. > > But more importantly you missed > > bit 0 (nohead): if cleared ('0'), then is included > in , and may be included in block>. If set ('1'), then and are not > included in . > > As for including a equal to zero, it's legal. > Not efficient, but legal. Right... I've missed that semantics part, simply because I've never seen a protocol header having a 'address semantics' field. Semantics is to me something to be specified in node behaviour, like when node receives this bit does that, but not to encode in messages... >> YEs, but this doesn't show the necessity of the third 'mid' part. >> There >> are only two parts: head and tail ('head' is first 64bits and 'tail' >> is >> the Interface ID or EUI-64). > > No, what I'm saying is that a node may use (using upper case letters > for 64 bits and a / to join them) A/Z and B/Z as two addresses of > the same interface, where Z is its EUI-64. Of course A and B may > also have some head bits in common, or may not. Right, that Z is the tail part. >> And 'mid'? > > mid is the uncompressed bit. Always is. Sometimes you have a common > head. Sometimes you have a common tail. Sometimes you have both. > Sometimes you have neither. mid is the bit in the middle that is > different. It can have zero length but that will be (I expect) > uncommon. 'mid' is one bit only? It seems to me it can have a length too: mid-length = address-length - head-length - tail-length. Anyways, would you agree a simple way to encode a NEMO Mobile Network Prefix with PacketBB would look like this (ignoring head:mid:tail features)(would you confirm the values of question marks?): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad '0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- IPv6 Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PrefixLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ num-addr: '1' addr-semantics: bit 0 (nohead): '1' bit 1 (notail): '0' bit 2 (zerotail): '0' bits 3-7: '0' tlv-length: ? tlv-type: ? tlv-semantics: bit 0 (extended): '0' bit 1 (novalue): '0' bit 2 (noindex): '1' bit 3 (singleindex): '0' bit 4 (multivalue): '?' bits 5-7: '0' length: 0x10 ('16' decimal) IPv6 address: the IPv6 address that is the Mobile Network Prefix. tlv-type2: '0' tlv-semantics2: '?' length2: '?' PrefixLen: Eight-bit unsigned integer indicating the prefix length of the IPv6 Address. I will post this separately as well. >> YEs, I agree, but there is much more here than just IPv6 address >> architecture once you say PacketBB packets are transported in UDP over >> IPv6... > > But invisibly to IPv6. packetbb is just carrying the addresses. > It's up to a protocol that does know something about addresses > - maybe DYMO, maybe an autoconf mechanism that uses packetbb > to interpret those addresses. packetbb is NOT a protocol. Well I agree PacketBB is not a protocol. However, and this is something I've already remarked to DYMO, ignoring some fields present in the IPv6 base header (ie rfc2460) is not good either. Also ignoring how other protocols encode addresses (and subsequently specifying new means) is too much programming effort when reuse could be more efficient. Just IMHO. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:23:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fYD-0000YR-8m; Tue, 19 Jun 2007 11:23:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fYB-0000YM-1S for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fYA-0000YE-O5 for manet@ietf.org; Tue, 19 Jun 2007 11:23:22 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0fYA-0007hX-Dl for manet@ietf.org; Tue, 19 Jun 2007 11:23:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1182266601!16618811!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15422 invoked from network); 19 Jun 2007 15:23:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 19 Jun 2007 15:23:21 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JFNA4E020839; Tue, 19 Jun 2007 08:23:21 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JFN9Ap017072; Tue, 19 Jun 2007 10:23:10 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JFN7qV016929; Tue, 19 Jun 2007 10:23:08 -0500 (CDT) Message-ID: <4677F4D5.3090109@gmail.com> Date: Tue, 19 Jun 2007 17:23:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] New definition of term 'TLV' in PacketBB References: <4677E42D.1040700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas Clausen wrote: > Alex, > > I appreciate your reviewing of the MANET WG specs. > > Generally, I think that it might be advantageous if you try to > understand WHY the specs are the way they are, rather than to launch > into observing a difference with some other similar mechanism and > then taking this as an indication that something is broken. Sorry, I didn't mean something was broken; just that it may be unnecessarily complex. > TLVs, for example, are TLVs, with the addendum of specifying "to > which entities they apply". This is necessary since it allows doing > efficient address aggregation. The alternative -- naive TLVs without > such information -- would lead to a much less efficient address > aggregation. (Notice that this is a simplified description, but that > it should get the point through) The other alternative of overspecifying new ways of encoding addresses risks obviously to create large packets for simpler cases. Whereas I agree head-mid-tail encodings of addresses can lead to smaller packets when several similar addresses are sent, apparently it sends more bytes than 'naive' TLV when only one address is sent. And this may be less efficient for MANEMO where often only one address/prefix is needed (the Mobile Network Prefix). > Since one of the MANET wg's design-dogmas is "efficient when > sensible", many such trade-offs have been considered and discussed > over the years, and packetbb reflects the result of a number of such > discussions. I agree with general consensus. I will send a separate email trying to identify how PacketBB can encode an IPv6 Mobile Network Prefix and then compare that encoding with the other existing ways of encoding Mobile Network Prefixes. Alex > > Thomas > > On Jun 19, 2007, at 4:11 PM, Alexandru Petrescu wrote: > >> Dearlove, Christopher (UK) wrote: >>>> I think the term TLV (type-length-value) is overloaded by the >>>> PacketBB >>> spec: There are many uses of TLV in many places. Some are simple, >>> some are more complicated. This one does the job it's intended to >>> do. >> >> But it's different than what rfc2460 calls a 'TLV'. >> >>> You actually can't do that job with just a type, a length and a >>> value as you then couldn't apply information to just some of the >>> addresses in an address block. And that's essential. I'm afraid I >>> don't find this particular criticism constructive, so I'm not >>> going to discuss this point further. >> >> Ok, I again went into MANET document debugging instead of >> contending just reading them :-( Generally speaking, I don't think >> it's constructive to ignore existence of already defined TLV >> mechanisms, address encoding mechanisms and code availability. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fa8-0002om-6N; Tue, 19 Jun 2007 11:25:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fa6-0002oe-4g for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fa5-0002oA-9A for manet@ietf.org; Tue, 19 Jun 2007 11:25:21 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fa4-0008D5-1C for manet@ietf.org; Tue, 19 Jun 2007 11:25:21 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0fa3-000Kqy-CN; Tue, 19 Jun 2007 11:25:19 -0400 X-MHO-User: U2FsdGVkX1+PouVXwYEELoIHpHbdObBd X-MHO-User: U2FsdGVkX1/WQVN/GMnd9szAopwtj2kr X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+naPrV3avnqIFzLjwBOecv In-Reply-To: <4677F35A.4030906@gmail.com> References: <4677F35A.4030906@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <431F42E6-C484-4459-B795-CB8EA2DD2D24@polytechnique.fr> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Three issues with PacketBB Date: Tue, 19 Jun 2007 17:25:19 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Alex, On Jun 19, 2007, at 5:16 PM, Alexandru Petrescu wrote: > > Right... I've missed that semantics part, simply because I've never > seen a protocol header having a 'address semantics' field. > Semantics is to me something to be specified in node behaviour, > like when node receives this bit does that, but not to encode in > messages... > This is not the intended meaning. semantics == "how you should interpret the encoded bit-sequence, in order to get an address out of it" What that address then means is for the node/protocol/whatever to determine. I wasn't aware that this could be ambiguously read from the text? >> mid is the uncompressed bit. Always is. Sometimes you have a common >> head. Sometimes you have a common tail. Sometimes you have both. >> Sometimes you have neither. mid is the bit in the middle that is >> different. It can have zero length but that will be (I expect) >> uncommon. > > 'mid' is one bit only? It seems to me it can have a length too: > mid-length = address-length - head-length - tail-length. > Chris meant to say: "mid is the uncompressed part" Which, yes, can be several bits long. > Anyways, would you agree a simple way to encode a NEMO Mobile > Network Prefix with PacketBB would look like this (ignoring > head:mid:tail features)(would you confirm the values of question > marks?): > I am sorry, it is not clear to me what you try to do. Are you intending to put an address into a TLV? If so, then while you possibly could do that, it's not the intended usage (addresses go in address blocks, possibly compressed) and I shall refrain from commenting on it. Or else, please try to explain what it is you are trying to do, since it is not clear. Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:31:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fgS-0008E7-TD; Tue, 19 Jun 2007 11:31:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fgR-00089u-9T for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:31:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fgQ-00089m-W8 for manet@ietf.org; Tue, 19 Jun 2007 11:31:55 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0fgQ-00012h-Ju for manet@ietf.org; Tue, 19 Jun 2007 11:31:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1182267111!1875318!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19423 invoked from network); 19 Jun 2007 15:31:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 19 Jun 2007 15:31:51 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JFVohx025382 for ; Tue, 19 Jun 2007 08:31:51 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5JFVnw7013179 for ; Tue, 19 Jun 2007 10:31:50 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5JFVkQ5013086 for ; Tue, 19 Jun 2007 10:31:47 -0500 (CDT) Message-ID: <4677F6E2.5000108@gmail.com> Date: Tue, 19 Jun 2007 17:31:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear MANETers. I'm trying to find out how to encode an IPv6 Mobile Network Prefix using PacketBB encoding rules. This is very important step in trying to use a MANET routing protocol in the MANEMO topologies, because eventually Mobile Network Prefixes have to be exchanged not only by the NEMO protocol but potentially by the MANET protocol as well. Reading the PacketBB spec, and with some helpful clarifications, I came up with the datagram I present first. I would need help to do the following: -first please confirm the encoding is correct. Are fields at right places, are the field lengths correct, have I missed any field, have I added too many fields, have I used padding correctly? -second please help me fill the values for the '?' marks. -finally, please compare the encoding with another encoding of the IPv6 Mobile Network Prefix presented at the end of the message. I think the latter uses less bytes to encode. Can I use the latter encoding but expressed with PAcketBB terms? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad '0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- IPv6 Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PrefixLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ num-addr: '1' addr-semantics: bit 0 (nohead): '1' bit 1 (notail): '0' bit 2 (zerotail): '0' bits 3-7: '0' tlv-length: ? tlv-type: ? tlv-semantics: bit 0 (extended): '0' bit 1 (novalue): '0' bit 2 (noindex): '1' bit 3 (singleindex): '0' bit 4 (multivalue): '?' bits 5-7: '0' length: 0x10 ('16' decimal) IPv6 address: the IPv6 address that is the Mobile Network Prefix. tlv-type2: '0' tlv-semantics2: '?' length2: '?' PrefixLen: Eight-bit unsigned integer indicating the prefix length of the IPv6 Address. Other (possibly simpler?) possible way of encoding the IPv6 Mobile Network Prefix, but not with PacketBB: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:42:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fqw-00013n-Dz; Tue, 19 Jun 2007 11:42:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fqu-000114-JQ for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fqu-00010v-9p for manet@ietf.org; Tue, 19 Jun 2007 11:42:44 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fqs-0003wO-VS for manet@ietf.org; Tue, 19 Jun 2007 11:42:44 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JFggBF001834 for ; Tue, 19 Jun 2007 16:42:42 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JFgf9c031811 for ; Tue, 19 Jun 2007 16:42:42 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 16:42:41 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 16:42:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Tue, 19 Jun 2007 16:42:40 +0100 Message-ID: In-Reply-To: <4677F6E2.5000108@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Thread-Index: Aceyhv60qs3VlF4ESt2BvrHfMJS0IgAAT7Ng From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "manet" X-OriginalArrivalTime: 19 Jun 2007 15:42:41.0153 (UTC) FILETIME=[7892C710:01C7B288] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I came up with the datagram I present first. I'm afraid I don't have time to comment on this. But that Pad octet is clearly out of place. Padding occurs (optionally) only after a packet header or a message. Also see Thomas's comments. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:44:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fsY-00022V-BD; Tue, 19 Jun 2007 11:44:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fsW-00022H-2q for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fsV-000229-PV for manet@ietf.org; Tue, 19 Jun 2007 11:44:23 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0fsV-0004WO-EZ for manet@ietf.org; Tue, 19 Jun 2007 11:44:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1182267862!1266251!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 12879 invoked from network); 19 Jun 2007 15:44:22 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-5.tower-153.messagelabs.com with SMTP; 19 Jun 2007 15:44:22 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l5JFiLTw006441; Tue, 19 Jun 2007 08:44:21 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JFiKmr014234; Tue, 19 Jun 2007 10:44:21 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JFiI0H014164; Tue, 19 Jun 2007 10:44:19 -0500 (CDT) Message-ID: <4677F9D1.9000704@gmail.com> Date: Tue, 19 Jun 2007 17:44:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] Three issues with PacketBB References: <4677F35A.4030906@gmail.com> <431F42E6-C484-4459-B795-CB8EA2DD2D24@polytechnique.fr> In-Reply-To: <431F42E6-C484-4459-B795-CB8EA2DD2D24@polytechnique.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas Clausen wrote: > Alex, > > On Jun 19, 2007, at 5:16 PM, Alexandru Petrescu wrote: > >> >> Right... I've missed that semantics part, simply because I've never >> seen a protocol header having a 'address semantics' field. >> Semantics is to me something to be specified in node behaviour, >> like when node receives this bit does that, but not to encode in >> messages... >> > > This is not the intended meaning. semantics == "how you should > interpret the encoded bit-sequence, in order to get an address out of > it" > > What that address then means is for the node/protocol/whatever to > determine. > > I wasn't aware that this could be ambiguously read from the text? Thanks for the explanation of what you mean by semantics of an address: how to interpret the bit sequence. Generally, I am of the oppinion that ROHC (RObust Header Compression) looks at several fields in an IP/UDP/TCP header and finds commonalities between them, not just at commonalities between addresses. I think with some tweaking ROHC could be used in some MANET networks (maybe a new MANET-ROHC profile?). >>> mid is the uncompressed bit. Always is. Sometimes you have a >>> common head. Sometimes you have a common tail. Sometimes you have >>> both. Sometimes you have neither. mid is the bit in the middle >>> that is different. It can have zero length but that will be (I >>> expect) uncommon. >> >> 'mid' is one bit only? It seems to me it can have a length too: >> mid-length = address-length - head-length - tail-length. >> > > Chris meant to say: > > "mid is the uncompressed part" > > Which, yes, can be several bits long. Ok, so this makes it for three parts of an IP address: head, mid and tail - each of variable length. >> Anyways, would you agree a simple way to encode a NEMO Mobile >> Network Prefix with PacketBB would look like this (ignoring >> head:mid:tail features)(would you confirm the values of question >> marks?): >> > > I am sorry, it is not clear to me what you try to do. Are you > intending to put an address into a TLV? If so, then while you > possibly could do that, it's not the intended usage (addresses go in > address blocks, possibly compressed) and I shall refrain from > commenting on it. Or else, please try to explain what it is you are > trying to do, since it is not clear. I am trying to encode an IPv6 Mobile Network Prefix (an IPv6 address and the prefixlength) with PacketBB rules. I understand for that I need to use a "Address Block TLV" for the prefix length, inserted within an Address Block after the Address TLV. Sorry, this may sound confusing, but that's how I understand it. I've sent a separate email depicting what I think PacketBB will result into when encoding an IPv6 Mobile Network Prefix. Please agree/disagree with that format. Otherwise please send a diagram with what you think PacketBB will result into when encoding an IPv6 Mobile Network Prefix (the IPv6 address and the prefix length). Thanks, Alex > > Thomas > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:47:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fv3-0002mq-Ly; Tue, 19 Jun 2007 11:47:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fv1-0002mf-V8 for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fv1-0002mX-Le for manet@ietf.org; Tue, 19 Jun 2007 11:46:59 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fv1-0005PK-Ak for manet@ietf.org; Tue, 19 Jun 2007 11:46:59 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0fv0-0002bC-8j; Tue, 19 Jun 2007 11:46:58 -0400 X-MHO-User: U2FsdGVkX19bTm92qfFiyL+9TWHOqBlj X-MHO-User: U2FsdGVkX18GY70yxdZLuCV3vmAX+Rsv X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qO9x/J6bmfCQzt9Tc+W9O In-Reply-To: <4677F4D5.3090109@gmail.com> References: <4677E42D.1040700@gmail.com> <4677F4D5.3090109@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <496D71EC-616D-4785-813C-87B24A1AACAE@polytechnique.fr> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] New definition of term 'TLV' in PacketBB Date: Tue, 19 Jun 2007 17:46:55 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Jun 19, 2007, at 5:23 PM, Alexandru Petrescu wrote: > Thomas Clausen wrote: >> Alex, >> I appreciate your reviewing of the MANET WG specs. >> Generally, I think that it might be advantageous if you try to >> understand WHY the specs are the way they are, rather than to launch >> into observing a difference with some other similar mechanism and >> then taking this as an indication that something is broken. > > Sorry, I didn't mean something was broken; just that it may be > unnecessarily complex. > Sorry, Alex, you can't just say that without understanding the context. Let me give an absurd example: I have 5 computers at home. In order to network those, I just need something simple. IPv6 addresses are too long, and all those IETF protocols are just unnecessarily complex. That's the same line of argument as you're usin: I've identified one particular case, and going by that case, I judge the world to be unnecessarily complex. packetbb is designed with a large set of conflicting constraints, including, but not limited to: - efficient packet/message size, including payloads and headers - simple parsing logic - extensibility/flexibility, such that we won't have to rewrite the spec (and our code) every time somebody has a new idea) and a whole host of other criteria that I shall not list here. A lot of effort has been made to try to balance those. Occasionally, some simplicity in the parsing logic has been sacrificed for improved compactness in the format. Occasionally it's the other way around. packetbb was designed as a building block for MANET wg protocols, and so has been discussed exhaustively in that context. Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:50:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fxy-0006M5-FU; Tue, 19 Jun 2007 11:50:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0fxx-0006Ly-FP for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fxx-0006Lg-5M for manet@ietf.org; Tue, 19 Jun 2007 11:50:01 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0fxu-0006RV-Ts for manet@ietf.org; Tue, 19 Jun 2007 11:50:01 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1182268197!30183244!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 9836 invoked from network); 19 Jun 2007 15:49:58 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-13.tower-119.messagelabs.com with SMTP; 19 Jun 2007 15:49:58 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l5JFnvYY002989; Tue, 19 Jun 2007 08:49:57 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JFnul2019590; Tue, 19 Jun 2007 10:49:57 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JFnsvn019528; Tue, 19 Jun 2007 10:49:55 -0500 (CDT) Message-ID: <4677FB21.3070904@gmail.com> Date: Tue, 19 Jun 2007 17:49:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> I came up with the datagram I present first. > > I'm afraid I don't have time to comment on this. Thanks, I request MANET community to comment on that PAcketBB encoding of the IPv6 Mobile Network PRefix - thank you. > But that Pad octet is clearly out of place. > Padding occurs (optionally) only after a packet > header or a message. Ok, I moved Pad '0' at the end, it looks like this, is this better? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || |IPv6 address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +- -+ | | +- IPv6 Address -+ | | +- +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PrefixLen | Pad '0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Also see Thomas's comments. I hope someone can comment on this packet format: ok or not ok, how should I encode it better? Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g4z-0001VG-Q1; Tue, 19 Jun 2007 11:57:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0g4y-0001V6-1w for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g4x-0001Uy-Oe for manet@ietf.org; Tue, 19 Jun 2007 11:57:15 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0g4u-00006s-QQ for manet@ietf.org; Tue, 19 Jun 2007 11:57:15 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1182268631!6862609!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14592 invoked from network); 19 Jun 2007 15:57:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 19 Jun 2007 15:57:11 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JFvBtO007861; Tue, 19 Jun 2007 08:57:11 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5JFvA7B003096; Tue, 19 Jun 2007 10:57:10 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5JFv8VG003052; Tue, 19 Jun 2007 10:57:08 -0500 (CDT) Message-ID: <4677FCD3.2020509@gmail.com> Date: Tue, 19 Jun 2007 17:57:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] New definition of term 'TLV' in PacketBB References: <4677E42D.1040700@gmail.com> <4677F4D5.3090109@gmail.com> <496D71EC-616D-4785-813C-87B24A1AACAE@polytechnique.fr> In-Reply-To: <496D71EC-616D-4785-813C-87B24A1AACAE@polytechnique.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas Clausen wrote: > > On Jun 19, 2007, at 5:23 PM, Alexandru Petrescu wrote: > >> Thomas Clausen wrote: >>> Alex, >>> I appreciate your reviewing of the MANET WG specs. >>> Generally, I think that it might be advantageous if you try to >>> understand WHY the specs are the way they are, rather than to launch >>> into observing a difference with some other similar mechanism and >>> then taking this as an indication that something is broken. >> >> Sorry, I didn't mean something was broken; just that it may be >> unnecessarily complex. >> > > Sorry, Alex, you can't just say that without understanding the context. > > Let me give an absurd example: > > I have 5 computers at home. In order to network those, I just need > something simple. IPv6 addresses are too long, and all those IETF > protocols are just unnecessarily complex. Haha, I think I understand what you mean. > That's the same line of argument as you're usin: I've identified one > particular case, and going by that case, I judge the world to be > unnecessarily complex. Right... I may have been wrong. The PacketBB is just complex, not necessarily "unnecessarily" complex. > packetbb is designed with a large set of conflicting constraints, > including, but not limited to: > > - efficient packet/message size, including payloads and headers > - simple parsing logic > - extensibility/flexibility, such that we won't have to rewrite the > spec > (and our code) every time somebody has a new idea) > > and a whole host of other criteria that I shall not list here. A lot of > effort has been made to try to balance those. Occasionally, some > simplicity in the parsing logic has been sacrificed for improved > compactness in the format. Occasionally it's the other way around. > > packetbb was designed as a building block for MANET wg protocols, and so > has been discussed exhaustively in that context. Ok Thomas, please don't take my remarks as discarding. PacketBB is designed for MANET protocols, identifies its commonalities, and respects many MANET requirements. I agree with what's designed by consensus and for a Working Group. Just please help me picture a PacketBB message (header or body) that contains an IPv6 Mobile Network Prefix (an IPv6 address and its prefix length). I want to do that correctly and according to existing consensus. I'm not looking for immediate feedback, just when you think it's possible. Or maybe I shouldn't ask for this encoding at all? Am I pushing in the wrong direction? Alex > > > Thomas > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 11:57:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g53-0001cJ-Hj; Tue, 19 Jun 2007 11:57:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0g51-0001Y2-Ui for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g51-0001X1-JJ for manet@ietf.org; Tue, 19 Jun 2007 11:57:19 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0g50-00008g-6m for manet@ietf.org; Tue, 19 Jun 2007 11:57:19 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JFvGPs009603 for ; Tue, 19 Jun 2007 16:57:16 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JFvGkl009384 for ; Tue, 19 Jun 2007 16:57:16 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 16:57:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 16:57:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Tue, 19 Jun 2007 16:57:16 +0100 Message-ID: In-Reply-To: <4677FB21.3070904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Thread-Index: AceyiYdL7uc9qjBQSFOuCCySRR0j6AAABv6w From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Jun 2007 15:57:16.0682 (UTC) FILETIME=[826DE6A0:01C7B28A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I hope someone can comment on this packet format: ok or not ok, how=20 > should I encode it better? Again, without studying it, what I would recommend is to take the regexp that is the formal definition, and break what you have down to match the elements in the regexp. As a starting exercise, take the example packet in Appendix B and do that to that. (You should actually be able to do it without reading the text before the example.) Hopefully you'll find it can be so decomposed. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g8A-0002op-5b; Tue, 19 Jun 2007 12:00:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0g7p-0002a0-63 for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g7n-0002ZW-C9 for manet@ietf.org; Tue, 19 Jun 2007 12:00:11 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0g7n-0000m2-3a for manet@ietf.org; Tue, 19 Jun 2007 12:00:11 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0g7l-0007ZM-7w; Tue, 19 Jun 2007 12:00:09 -0400 X-MHO-User: U2FsdGVkX19XEfOP3BN0dPoxG6nNnAwi X-MHO-User: U2FsdGVkX19YwcNplNs3340PT3vpRkPW X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19wsLlCncjg6H2zMbGq6YHH In-Reply-To: <4677FB21.3070904@gmail.com> References: <4677FB21.3070904@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Tue, 19 Jun 2007 18:00:08 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Jun 19, 2007, at 5:49 PM, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) wrote: >>> I came up with the datagram I present first. >> I'm afraid I don't have time to comment on this. > > Thanks, I request MANET community to comment on that PAcketBB > encoding of the IPv6 Mobile Network PRefix - thank you. > I still do not think that it is clear what it is you are trying to encode, and your figure doesn't help. What is it that you are trying to do? In your figure, it seems that you are trying to have part of an address block header and then a TLV block followed by an IPv6 address.....then another TLV block and some padding. Doesn't look to me as this encoding would be compatible with packetbb, but if I understood what it was you were trying to do, then I am sure that it could be encoded. Have you looked at draft-ietf-manet-packetbb (here's an URL: http:// www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt) section 5 for the description of the format, and appendix A for illustrations? It should provide you with inspiration as to how you can encode things, once they're specified, and examples of how the actual layout would be in the familiar IETF-pictures. If all you want is a single IPv6 prefix, then you'd benefit little from any aggregation, and a message TLV with explicit content might simply do the trick. But, I am not sure I understand if that is what you are looking for. Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gGd-0006T4-Gh; Tue, 19 Jun 2007 12:09:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0gGc-0006Sz-8a for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:09:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gGb-0006Rq-Ti for manet@ietf.org; Tue, 19 Jun 2007 12:09:17 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0gGa-0002dk-LE for manet@ietf.org; Tue, 19 Jun 2007 12:09:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1182269355!18134918!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9218 invoked from network); 19 Jun 2007 16:09:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 19 Jun 2007 16:09:15 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JG9Fb2011851; Tue, 19 Jun 2007 09:09:15 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5JG9FDI029704; Tue, 19 Jun 2007 11:09:15 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JG9Dsg029693; Tue, 19 Jun 2007 11:09:14 -0500 (CDT) Message-ID: <4677FFA9.7070305@gmail.com> Date: Tue, 19 Jun 2007 18:09:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "manet@ietf.org >> manet" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> I hope someone can comment on this packet format: ok or not ok, how >> should I encode it better? > > Again, without studying it, what I would recommend is to take the > regexp that is the formal definition, and break what you have down to > match the elements in the regexp. That's what I did. ('regexp' means different things to different people: "?" has different meanings in gnu regexp vs dragon book - which one did you use? Besides, I'm not used to reading messages specified with grammar syntaxes, but I could try to understand the Augmented Backus-Naur Form RFC4234 which incidentally doesn't use '?' at all.) > As a starting exercise, take the example packet in Appendix B and do > that to that. (You should actually be able to do it without reading > the text before the example.) Hopefully you'll find it can be so > decomposed. I've tried that too. But it uses IPv4 addresses; and head-mid parts. DYMO example too uses IPv4 addresses. My example only needs to encode one address so it doesn't use head-mid-tail parts. The example in Appendix B is very useful when one needs IPv4 encoding and sending two or more addresses. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gIV-0001QK-4b; Tue, 19 Jun 2007 12:11:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0gIT-0001KJ-5l for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gIS-0001In-PE for manet@ietf.org; Tue, 19 Jun 2007 12:11:12 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gIR-0002u9-Ee for manet@ietf.org; Tue, 19 Jun 2007 12:11:12 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5JGB6Se002065 for ; Tue, 19 Jun 2007 17:11:06 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5JGB6cG015572 for ; Tue, 19 Jun 2007 17:11:06 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 19 Jun 2007 17:11:06 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:11:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Tue, 19 Jun 2007 17:11:06 +0100 Message-ID: In-Reply-To: <4677FFA9.7070305@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Thread-Index: AceyjDMzSBGbjlTiQRWLyre9u+FL5AAACdIQ From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Jun 2007 16:11:06.0273 (UTC) FILETIME=[70E77110:01C7B28C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org ('regexp' means different things to different people: "?" has different meanings in gnu regexp vs dragon book - which one did you use? Defined in the Terminology section. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:16:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gNk-0007bN-AJ; Tue, 19 Jun 2007 12:16:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0gNj-0007bI-0T for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gNi-0007YC-Jv for manet@ietf.org; Tue, 19 Jun 2007 12:16:38 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0gNi-00046R-70 for manet@ietf.org; Tue, 19 Jun 2007 12:16:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1182269797!1927009!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18847 invoked from network); 19 Jun 2007 16:16:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 19 Jun 2007 16:16:37 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JGGank014428; Tue, 19 Jun 2007 09:16:36 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5JGGa3a018624; Tue, 19 Jun 2007 11:16:36 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5JGGYH1018595; Tue, 19 Jun 2007 11:16:34 -0500 (CDT) Message-ID: <46780161.8070509@gmail.com> Date: Tue, 19 Jun 2007 18:16:33 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB References: <4677FB21.3070904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas Clausen wrote: > > On Jun 19, 2007, at 5:49 PM, Alexandru Petrescu wrote: > >> Dearlove, Christopher (UK) wrote: >>>> I came up with the datagram I present first. >>> I'm afraid I don't have time to comment on this. >> >> Thanks, I request MANET community to comment on that PAcketBB >> encoding of the IPv6 Mobile Network PRefix - thank you. >> > > I still do not think that it is clear what it is you are trying to > encode, and your figure doesn't help. What is it that you are trying > to do? In your figure, it seems that you are trying to have part of > an address block header and then a TLV block followed by an IPv6 > address.....then another TLV block and some padding. > > Doesn't look to me as this encoding would be compatible with > packetbb, but if I understood what it was you were trying to do, then > I am sure that it could be encoded. > > Have you looked at draft-ietf-manet-packetbb (here's an URL: > http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt) > section 5 for the description of the format, and appendix A for > illustrations? It should provide you with inspiration as to how you > can encode things, once they're specified, and examples of how the > actual layout would be in the familiar IETF-pictures. YEs I've looked at these sections. I have plenty of remarks on them. I refrain from writing remarks about the way that section is written, for fearing of risking be not well understood. All I need is a consensus-based PacketBB message that contains an IPv6 address with an IPv6 prefix length on it. Just one, not two. No head-mid-tail and no index-start nor index-stop. I've tried to propose one as I understand it. Would you please remark whether you agree with that message or not and why - thank you. > If all you want is a single IPv6 prefix, then you'd benefit little > from any aggregation, and a message TLV with explicit content might > simply do the trick. But, I am not sure I understand if that is what > you are looking for. YEs, that is what I am looking for: a PacketBB message TLV with explicit content, containing an IPv6 Mobile Network Prefix (an IPv6 address and the prefix length). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:19:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gQf-0004iO-Kq; Tue, 19 Jun 2007 12:19:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0gQc-0004hz-TC for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gQc-0004hj-J1 for manet@ietf.org; Tue, 19 Jun 2007 12:19:38 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gQb-0005Ep-CJ for manet@ietf.org; Tue, 19 Jun 2007 12:19:38 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0gQV-000ER3-LV; Tue, 19 Jun 2007 12:19:31 -0400 X-MHO-User: U2FsdGVkX1++94oy4Vgf31svFcNTaRVx X-MHO-User: U2FsdGVkX19d22NtNOnyZrEnyzfmbUZh X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/lz/p9bWibsm/6uBjrxlBp In-Reply-To: <4677FFA9.7070305@gmail.com> References: <4677FFA9.7070305@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Tue, 19 Jun 2007 18:19:32 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org >> manet" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Jun 19, 2007, at 6:09 PM, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) wrote: >>> I hope someone can comment on this packet format: ok or not ok, how >>> should I encode it better? >> Again, without studying it, what I would recommend is to take the >> regexp that is the formal definition, and break what you have down to >> match the elements in the regexp. > > That's what I did. > > ('regexp' means different things to different people: "?" has > different > meanings in gnu regexp vs dragon book - which one did you use? > Besides, I'm not used to reading messages specified with grammar > syntaxes, but I could try to understand the Augmented Backus-Naur > Form > RFC4234 which incidentally doesn't use '?' at all.) > The "?" and other such symbols used are described in the terminology section, exactly recognizing that it might be differently interpreted if not defined. Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:25:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWS-0000Ki-By; Tue, 19 Jun 2007 12:25:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0gWP-0000Kd-WB for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWP-0000KU-Mi for manet@ietf.org; Tue, 19 Jun 2007 12:25:37 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0gWO-0006de-Bp for manet@ietf.org; Tue, 19 Jun 2007 12:25:37 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1182270333!6676092!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 855 invoked from network); 19 Jun 2007 16:25:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 19 Jun 2007 16:25:34 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JGPXUM017272; Tue, 19 Jun 2007 09:25:33 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l5JGPXTI000474; Tue, 19 Jun 2007 11:25:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5JGPV5I000456; Tue, 19 Jun 2007 11:25:32 -0500 (CDT) Message-ID: <4678037B.2090007@gmail.com> Date: Tue, 19 Jun 2007 18:25:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: > ('regexp' means different things to different people: "?" has different > meanings in gnu regexp vs dragon book - which one did you use? > > Defined in the Terminology section. Yes, ok. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 12:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gYr-0003VU-6p; Tue, 19 Jun 2007 12:28:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0gYp-0003VN-OS for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gYp-0003VE-DD for manet@ietf.org; Tue, 19 Jun 2007 12:28:07 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gYo-00080u-2U for manet@ietf.org; Tue, 19 Jun 2007 12:28:07 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0gYn-000HOg-GF; Tue, 19 Jun 2007 12:28:05 -0400 X-MHO-User: U2FsdGVkX1+HEZQxgT6BFxEvhmMnrCeA X-MHO-User: U2FsdGVkX18zr68Jxp6Fvndd3ShEkBaH X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19SDXWTbhn5hJfh+w+mbBxJ In-Reply-To: <46780161.8070509@gmail.com> References: <4677FB21.3070904@gmail.com> <46780161.8070509@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Tue, 19 Jun 2007 18:28:06 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Jun 19, 2007, at 6:16 PM, Alexandru Petrescu wrote: > Thomas Clausen wrote: >> On Jun 19, 2007, at 5:49 PM, Alexandru Petrescu wrote: >>> Dearlove, Christopher (UK) wrote: >>>>> I came up with the datagram I present first. >>>> I'm afraid I don't have time to comment on this. >>> Thanks, I request MANET community to comment on that PAcketBB >>> encoding of the IPv6 Mobile Network PRefix - thank you. >> I still do not think that it is clear what it is you are trying to >> encode, and your figure doesn't help. What is it that you are trying >> to do? In your figure, it seems that you are trying to have part of >> an address block header and then a TLV block followed by an IPv6 >> address.....then another TLV block and some padding. >> Doesn't look to me as this encoding would be compatible with >> packetbb, but if I understood what it was you were trying to do, then >> I am sure that it could be encoded. >> Have you looked at draft-ietf-manet-packetbb (here's an URL: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt) >> section 5 for the description of the format, and appendix A for >> illustrations? It should provide you with inspiration as to how you >> can encode things, once they're specified, and examples of how the >> actual layout would be in the familiar IETF-pictures. > > YEs I've looked at these sections. I have plenty of remarks on > them. I > refrain from writing remarks about the way that section is written, > for > fearing of risking be not well understood. > > All I need is a consensus-based PacketBB message that contains an IPv6 > address with an IPv6 prefix length on it. Just one, not two. No > head-mid-tail and no index-start nor index-stop. Let me play devils advocate: you want a packetbb message that's not a packetbb message? > > I've tried to propose one as I understand it. Would you please remark > whether you agree with that message or not and why - thank you. > Ok, I do not agree with that message you proposed. Why? Because it is not a validly formed packetbb message. >> If all you want is a single IPv6 prefix, then you'd benefit little >> from any aggregation, and a message TLV with explicit content might >> simply do the trick. But, I am not sure I understand if that is what >> you are looking for. > > YEs, that is what I am looking for: a PacketBB message TLV with > explicit > content, containing an IPv6 Mobile Network Prefix (an IPv6 address and > the prefix length). Very well. Seeing that you want that and only that one single prefix ever, then I'd go with a message TLV and an explicit representation of the prefix. See the examples in appendix A for how such a message TLV would look. However if you might have more prefixes to advertise, or more addresses, then this would not be the efficient solution. But, I feel that you're either aiming for a very specific situation -- or for demonstrating something specific -- so I am not sure to which extend it is helpful that I comment on that without knowing the whole design- space you are considering. Please do not take this as not-wanting-to-help -- but as the prudence that good engineers have to exhibit in not proposing a solution without understanding the problem and the design-space. Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 13:42:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hj4-00037R-DD; Tue, 19 Jun 2007 13:42:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0hj2-00037M-A0 for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 13:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hj2-00037E-09 for manet@ietf.org; Tue, 19 Jun 2007 13:42:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0hj1-0008S8-KA for manet@ietf.org; Tue, 19 Jun 2007 13:42:43 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2007 10:42:43 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="163358718:sNHT51003036" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5JHghqo019424; Tue, 19 Jun 2007 10:42:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JHgO2S011932; Tue, 19 Jun 2007 17:42:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:42:42 -0700 Received: from [10.32.244.218] ([10.32.244.218]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:42:42 -0700 In-Reply-To: <4677D538.4040206@gmail.com> References: <4677D538.4040206@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A5A4BC8-98E9-4B9D-A546-817B79C9092B@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [manet] New definition of term 'TLV' in PacketBB Date: Tue, 19 Jun 2007 10:42:39 -0700 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Jun 2007 17:42:42.0425 (UTC) FILETIME=[3CDDAE90:01C7B299] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2589; t=1182274963; x=1183138963; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[manet]=20New=20definition=20of=20term=20'TLV'=20in=2 0PacketBB |Sender:=20; bh=Ic4uLevwBRih3An2U8escdVFSoVlO1iw9KMmt5HSyn4=; b=qE90Kh927kmzmi8vvpGkWX5AqLQQJfvk/ahUpfu9bX9vge0SXq9eq86478+vHnFt1LZzJlrK NvE2Kbb97JKj6dtgvfGlD8G024cd4O6ViJp+XgFTrLjJPBd+rVjuX1HuawBp+QRD+C6xh8BeYm RM+YP1W4/YkOdMWwdh7ZtMfnI=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I partly agree. TLV is a generic term describing any encoding that includes the concept of a type, a length, and a value. There is no specific requirement about octet boundaries either; to name one example RSVP's generic TLV looks like this (from RFC 2205): 3.1.2 Object Formats Every object consists of one or more 32-bit words with a one- word header, with the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ That said, this particular TLV could be called a PacketBB TLV, or a PacketBB Information Element. It would be entirely appropriate to go on to describe in detail the format and intended structure of the TLV. Dumb question: what makes this specific to manet? Why is this not "how to design an internet message"? On Jun 19, 2007, at 6:08 AM, Alexandru Petrescu wrote: > I think the term TLV (type-length-value) is overloaded by the > PacketBB spec: > > > is defined by: > > > > = > > > > ? > > ? > > ? > > ? > > In many RFCs "TLV" is used to just mean Type-Length-Value, with > Type and > Length represented each on one byte and the Value on Length bytes. > > I think when generally people talk about TLV they really mean this > simplicity afforded by type-length-value as opposed to encoding > additional things like semantics, index, etc. > > IMHO we should use TLV as simply type-length-value instead of encoding > additional semantics and index. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 14:58:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iuM-0004jC-9C; Tue, 19 Jun 2007 14:58:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0iuK-0004j2-MQ for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 14:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iuK-0004iu-Cu for manet@ietf.org; Tue, 19 Jun 2007 14:58:28 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0iuK-00064f-2p for manet@ietf.org; Tue, 19 Jun 2007 14:58:28 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1182279506!20431905!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 28194 invoked from network); 19 Jun 2007 18:58:26 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-10.tower-119.messagelabs.com with SMTP; 19 Jun 2007 18:58:26 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l5JIwQ2J013583; Tue, 19 Jun 2007 11:58:26 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5JIwPfr027782; Tue, 19 Jun 2007 13:58:25 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.219]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5JIwLga027744; Tue, 19 Jun 2007 13:58:22 -0500 (CDT) Message-ID: <4678274C.7000704@gmail.com> Date: Tue, 19 Jun 2007 20:58:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fred Baker Subject: Re: [manet] New definition of term 'TLV' in PacketBB References: <4677D538.4040206@gmail.com> <1A5A4BC8-98E9-4B9D-A546-817B79C9092B@cisco.com> In-Reply-To: <1A5A4BC8-98E9-4B9D-A546-817B79C9092B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-2, 19/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Fred Baker wrote: > I partly agree. TLV is a generic term describing any encoding that > includes the concept of a type, a length, and a value. There is no > specific requirement about octet boundaries either; to name one example > RSVP's generic TLV looks like this (from RFC 2205): > > 3.1.2 Object Formats > > Every object consists of one or more 32-bit words with a one- > word header, with the following format: > > 0 1 2 3 > +-------------+-------------+-------------+-------------+ > | Length (bytes) | Class-Num | C-Type | > +-------------+-------------+-------------+-------------+ > | | > // (Object contents) // > | | > +-------------+-------------+-------------+-------------+ > > > That said, this particular TLV could be called a PacketBB TLV, or a > PacketBB Information Element. It would be entirely appropriate to go on > to describe in detail the format and intended structure of the TLV. I think yes, it would be appropriate to call it a PacketBB TLV or a PacketBB Information Element. > Dumb question: what makes this specific to manet? Why is this not "how > to design an internet message"? I would also like to learn more about this. I currently think having heard two reasons: (1) PacketBB is one way people used to try to converge between OLSR and DYMO. I think this is a good approach - try to encode things in the same way, by both protocols, eventually leading to one MANET protocol. But this does not motivate it being so complex, IMHO. (2) MANETs are very much risking to run on bandwidth-constrained links, thus try to optimize (read compress) as much as possible what's being transmitted. Which is generally a good principle (be conservative in what you send etc). But seems to ignore that many other IETF communities looked exactly at same bandwidth-constrained links and already came up with similar mechanisms, one notable being ROHC. Also, designers seem to overlook the fact that it is possible to achieve short messages by other means than compressing, as it is possible to have secure mechanisms without using crypto. Anyways, this is one big IMHO and I'm interested to learn more about MANET members' oppinions on this topic. Alex > > On Jun 19, 2007, at 6:08 AM, Alexandru Petrescu wrote: > >> I think the term TLV (type-length-value) is overloaded by the PacketBB >> spec: >> >> > is defined by: >> > >> > = >> > >> > ? >> > ? >> > ? >> > ? >> >> In many RFCs "TLV" is used to just mean Type-Length-Value, with Type and >> Length represented each on one byte and the Value on Length bytes. >> >> I think when generally people talk about TLV they really mean this >> simplicity afforded by type-length-value as opposed to encoding >> additional things like semantics, index, etc. >> >> IMHO we should use TLV as simply type-length-value instead of encoding >> additional semantics and index. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 19 15:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jIv-0002pe-0T; Tue, 19 Jun 2007 15:23:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0jIt-0002pU-UD for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jIt-0002pH-Js for manet@ietf.org; Tue, 19 Jun 2007 15:23:51 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0jIs-0002ft-SL for manet@ietf.org; Tue, 19 Jun 2007 15:23:51 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1182280629!17568735!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4593 invoked from network); 19 Jun 2007 19:17:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 19 Jun 2007 19:17:09 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JJH9Va006742; Tue, 19 Jun 2007 12:17:09 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5JJH8BD019351; Tue, 19 Jun 2007 14:17:09 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.219]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JJH59h019307; Tue, 19 Jun 2007 14:17:06 -0500 (CDT) Message-ID: <46782BB1.8080404@gmail.com> Date: Tue, 19 Jun 2007 21:17:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB References: <4677FB21.3070904@gmail.com> <46780161.8070509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-2, 19/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: "Dearlove, Christopher \(UK\)" , Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas Clausen wrote: > > On Jun 19, 2007, at 6:16 PM, Alexandru Petrescu wrote: > >> Thomas Clausen wrote: >>> On Jun 19, 2007, at 5:49 PM, Alexandru Petrescu wrote: >>>> Dearlove, Christopher (UK) wrote: >>>>>> I came up with the datagram I present first. >>>>> I'm afraid I don't have time to comment on this. >>>> Thanks, I request MANET community to comment on that PAcketBB >>>> encoding of the IPv6 Mobile Network PRefix - thank you. >>> I still do not think that it is clear what it is you are trying >>> to encode, and your figure doesn't help. What is it that you are >>> trying to do? In your figure, it seems that you are trying to >>> have part of an address block header and then a TLV block >>> followed by an IPv6 address.....then another TLV block and some >>> padding. Doesn't look to me as this encoding would be compatible >>> with packetbb, but if I understood what it was you were trying to >>> do, then I am sure that it could be encoded. Have you looked at >>> draft-ietf-manet-packetbb (here's an URL: >>> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-05.txt) >>> section 5 for the description of the format, and appendix A for >>> illustrations? It should provide you with inspiration as to how >>> you can encode things, once they're specified, and examples of >>> how the actual layout would be in the familiar IETF-pictures. >> >> YEs I've looked at these sections. I have plenty of remarks on >> them. I refrain from writing remarks about the way that section is >> written, for fearing of risking be not well understood. >> >> All I need is a consensus-based PacketBB message that contains an >> IPv6 address with an IPv6 prefix length on it. Just one, not two. >> No head-mid-tail and no index-start nor index-stop. > > Let me play devils advocate: you want a packetbb message that's not a > packetbb message? Hehe... no, I want a packetbb message that shows how one IPv6 Mobile Network Prefix (an IPv6 address and its prefix length) is encoded. If that packetbb messages forces the use of fields head-mid-tail and of index-start and index-stop then so be it, I just want to see it correctly. But I understood some of these fields are somehow optional. >> I've tried to propose one as I understand it. Would you please >> remark whether you agree with that message or not and why - thank >> you. >> > > Ok, I do not agree with that message you proposed. Why? Because it is > not a validly formed packetbb message. Would you help illustrating a correctly-formed packetbb message containing one IPv6 Address with its prefix length? This is very useful for MANEMO advancement. >>> If all you want is a single IPv6 prefix, then you'd benefit >>> little from any aggregation, and a message TLV with explicit >>> content might simply do the trick. But, I am not sure I >>> understand if that is what you are looking for. >> >> YEs, that is what I am looking for: a PacketBB message TLV with >> explicit content, containing an IPv6 Mobile Network Prefix (an IPv6 >> address and the prefix length). > > Very well. Seeing that you want that and only that one single prefix > ever, Ok, I understand what you mean. It's not that only one prefix will ever be sent, but just that generally people understand better when one prefix is illustrated and then explained how more prefixes can be encoded. > then I'd go with a message TLV and an explicit representation of the > prefix. See the examples in appendix A for how such a message TLV > would look. Ok, thanks. But Appendix A has 38 messages into it - which one? There are 6 subsections called "Packet", "Message and Padding", "Message Body", "Address Block", "TLV Block" and "TLV". None of them is called "message TLV". To be quicker, it would be easier if you could just paste from that Appendix which one do you mean, don't you think? Do you mean this? (yes/no?): > Appendix A.6. TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Resv |M|0|0|0|0| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Is this format sufficient to represent an IPv6 address and its prefix? Two of these? > However if you might have more prefixes to advertise, or more > addresses, then this would not be the efficient solution. But, I feel > that you're either aiming for a very specific situation -- or for > demonstrating something specific -- so I am not sure to which extend > it is helpful that I comment on that without knowing the whole > design-space you are considering. I think we understand each other well at this point. I'm aiming first to encode an IPv6 Mobile Network Prefix. Once I see how one is encoded then I can understand if and how several prefixes can be encoded. Encoding one IPv6 Mobile Network Prefix is very commonplace in some NEMO implementations. > Please do not take this as not-wanting-to-help -- but as the prudence > that good engineers have to exhibit in not proposing a solution > without understanding the problem and the design-space. Yes, right... that's exactly what I'm trying to describe for MANEMO - design space of using MANET routing protocols for MANEMO, and one problem is that I simply don't know how to encode an IPv6 Mobile Network Prefix in the UDP payload of a MANET protocol (with PacketBB). There are other issues that need to be discussed, some have already been raised, more to come. But let me first identify this PacketBB encoding of an IPv6 Mobile Network Prefix. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 04:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vtV-0001qH-45; Wed, 20 Jun 2007 04:50:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0vtS-0001q2-W8 for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 04:50:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vtS-0001pr-Jh for manet@ietf.org; Wed, 20 Jun 2007 04:50:26 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0vtR-0002cS-2V for manet@ietf.org; Wed, 20 Jun 2007 04:50:26 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5K8oMFj022791 for ; Wed, 20 Jun 2007 09:50:22 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5K8oMQo009013 for ; Wed, 20 Jun 2007 09:50:22 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 20 Jun 2007 09:50:21 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:50:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Wed, 20 Jun 2007 09:50:20 +0100 Message-ID: In-Reply-To: <1A5A4BC8-98E9-4B9D-A546-817B79C9092B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New definition of term 'TLV' in PacketBB Thread-Index: AceymUW0mQeveswLRey0yCjxf3+nEgAfKfvw From: "Dearlove, Christopher \(UK\)" To: "Fred Baker" , "Alexandru Petrescu" X-OriginalArrivalTime: 20 Jun 2007 08:50:21.0476 (UTC) FILETIME=[08FD6640:01C7B318] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Dumb question: what makes this specific to manet? Why is this not =20 > "how to design an internet message"? packetbb started as a more efficient format for OLSRv2. (And had no one else been interested that's where it would have stayed - and we'd go back to that if necessary.) The basic design (for which I can't claim credit) noted that OLSR is basically about a node expressing relationships with its neighbours - I can hear him, I have a symmetric link to him, he's my MPR. The format evolved from that. There's also some non-address specific stuff, and it kept the OLSR message header, with minor changes, as that allowed efficient "do I process and/or forward this" decisions. This did produce something with wider application than OLSR, and the SMF and DYMO authors thought they could use it. Various things were done to accommodate some extra requirements (such as not having to have all of the header) and some additional efficiency options in TLVs. These are all in the Manet group of course, but maybe people in the Autoconf group may use it. But as you note, it's not MANET specific - but we've branded it that way as the Manet WG is tasked to produce MANET protocols, of which this is an essential component (and why we need to get this done). We felt that branding it as a general purpose format would lead to delays as people outside the MANET community would feel they needed to be consulted etc. (I'm not arguing they would be wrong - after all, we haven't considered all of their requirements.) But if anyone outside the MANET community wants to use it "as is" - or use it as the basis for something else, we'd be very happy. The underlying assumptions that produced it are after all, as you note, more widely applicable than MANETs, or even than routing protocols. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 05:32:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wY8-0000c3-DZ; Wed, 20 Jun 2007 05:32:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0wY7-0000bw-HV for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wY7-0000bn-7k for manet@ietf.org; Wed, 20 Jun 2007 05:32:27 -0400 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wY5-0005BH-Up for manet@ietf.org; Wed, 20 Jun 2007 05:32:27 -0400 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:32:24 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:32:24 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Wed, 20 Jun 2007 11:33:20 +0200 Message-ID: <003601c7b31e$0a8afc60$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AceymUW0mQeveswLRey0yCjxf3+nEgAfKfvwAAHAF1A= X-OriginalArrivalTime: 20 Jun 2007 09:32:24.0263 (UTC) FILETIME=[E8B02570:01C7B31D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > This did produce something with wider application than > OLSR, and the SMF and DYMO authors thought they could > use it. Sometimes it is mentioned PacketBB is used in SMF. There was a discussion on this in Prague also. I posted before Joe was right and PacketBB is not used in SMF. SMF can make use of NHDP and NHDP makes use of PacketBB. But SMF will work without NHDP and performs CF-based forwarding or can use other sources for relay set information. By the way, I think the origin of the name PacketBB should be described somewhere. Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 05:37:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wcg-0001UC-QP; Wed, 20 Jun 2007 05:37:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0wce-0001Tq-QQ for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wce-0001Ti-Em for manet@ietf.org; Wed, 20 Jun 2007 05:37:08 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wcd-0005ws-43 for manet@ietf.org; Wed, 20 Jun 2007 05:37:08 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5K9b6wD026604 for ; Wed, 20 Jun 2007 10:37:06 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5K9b60g018155 for ; Wed, 20 Jun 2007 10:37:06 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 20 Jun 2007 10:37:05 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:37:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Wed, 20 Jun 2007 10:37:04 +0100 Message-ID: In-Reply-To: <003601c7b31e$0a8afc60$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New definition of term 'TLV' in PacketBB Thread-Index: AceymUW0mQeveswLRey0yCjxf3+nEgAfKfvwAAHAF1AAAGXhMA== From: "Dearlove, Christopher \(UK\)" To: "Teco Boot" X-OriginalArrivalTime: 20 Jun 2007 09:37:05.0408 (UTC) FILETIME=[90437800:01C7B31E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > By the way, I think the origin of the name PacketBB should > be described somewhere. If it were permanent, yes. But the only place it occurs is in the ID name, and that will go when it becomes an RFC. (This is typical, zeroconf is an obvious example.) bb =3D building block, however. Or so I'm told. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 05:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wkG-0005XE-HG; Wed, 20 Jun 2007 05:45:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0wkE-0005X6-M6 for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wkE-0005Wu-CQ for manet@ietf.org; Wed, 20 Jun 2007 05:44:58 -0400 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wkB-0006yl-Vb for manet@ietf.org; Wed, 20 Jun 2007 05:44:58 -0400 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:44:55 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:44:51 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Wed, 20 Jun 2007 11:45:47 +0200 Message-ID: <003701c7b31f$c7c2f7f0$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AceymUW0mQeveswLRey0yCjxf3+nEgAfKfvwAAHAF1AAAGXhMAAANkwA X-OriginalArrivalTime: 20 Jun 2007 09:44:51.0335 (UTC) FILETIME=[A5FA4970:01C7B31F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Besides a lot of references in ML and refs to the ID, I found a ref to "PacketBB" in the DYMO ID, section 4.2: +----------------------------+-------------------+ | Information Location | Notational Prefix | +----------------------------+-------------------+ | IP header | IP. | | UDP header | UDP. | | packetbb message header | MsgHdr. | | packetbb message TLV | MsgTLV. | | packetbb address blocks | AddBlk. | | packetbb address block TLV | AddTLV. | +----------------------------+-------------------+ Anyway, we need a name for the packet building block. Teco. > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: woensdag 20 juni 2007 11:37 > To: Teco Boot > Cc: manet > Subject: RE: [manet] New definition of term 'TLV' in PacketBB > > > > By the way, I think the origin of the name PacketBB should > > be described somewhere. > > If it were permanent, yes. But the only place it > occurs is in the ID name, and that will go when it > becomes an RFC. (This is typical, zeroconf is an > obvious example.) > > bb = building block, however. Or so I'm told. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 05:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wmA-0001yO-2m; Wed, 20 Jun 2007 05:46:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0wm8-0001r0-LR for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wm8-0001qU-BH for manet@ietf.org; Wed, 20 Jun 2007 05:46:56 -0400 Received: from hedwig.lancs.ac.uk ([148.88.0.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wm6-0007Dj-QJ for manet@ietf.org; Wed, 20 Jun 2007 05:46:56 -0400 Received: from mail02.lancs.ac.uk ([148.88.1.54]) by hedwig.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1I0wm6-00022k-AR for manet@ietf.org; Wed, 20 Jun 2007 10:46:54 +0100 Received: from inc020000006.lancs.ac.uk ([148.88.224.75] helo=INC020000006) by mail02.lancs.ac.uk with esmtp (Exim 4.66) (envelope-from ) id 1I0wm5-0006dd-Mo for manet@ietf.org; Wed, 20 Jun 2007 10:46:53 +0100 From: "Rajiv Ramdhany" To: Date: Wed, 20 Jun 2007 10:46:51 +0100 Organization: Lancaster University Message-ID: <000601c7b31f$ed9a9f00$4be05894@lancs.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcezH+1qfibJET7BS662g8mHLEQccw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Subject: [manet] OLSRv2, PacketBB, NHDP java implementations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096902984==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1096902984== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7B328.4F5F0700" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7B328.4F5F0700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Could anybody let me know of any Java implementation of OLSRv2, PacketBB and NHDP. I'm working on a reflective component-based ad hoc routing framework. Java open-source implementations of the above would help me cut down on development effort and spend more time on the real problems. Thanks, Rajiv ___________________________________________________ Rajiv Ramdhany, Computing Dept., Infolab21, Lancaster University, Lancaster LA1 4YW. Phone: +44 015245 10341 Email: r.ramdhany@lancaster.ac.uk "There's nothing permanent except change." Heraclitus of Ephesus (535-475 BC) ------=_NextPart_000_0007_01C7B328.4F5F0700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Could anybody let me know of any Java implementation = of OLSRv2, PacketBB and NHDP. I’m working on a reflective = component-based ad hoc routing framework. Java open-source implementations of the above = would help me cut down on development effort and spend more time on the real = problems.

 

Thanks,

Rajiv

 

 

 

___________________________________________________

Rajiv Ramdhany,

Computing Dept., = Infolab21,

Lancaster University,<= /p>

Lancaster LA1 = 4YW.

 

Phone: +44 015245 10341

Email: r.ramdhany@lancaster= .ac.uk

 

"There's nothing permanent except = change."
Heraclitus of Ephesus = (535-475 BC)

 

------=_NextPart_000_0007_01C7B328.4F5F0700-- --===============1096902984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1096902984==-- From manet-bounces@ietf.org Wed Jun 20 05:48:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wnS-0003ow-OW; Wed, 20 Jun 2007 05:48:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0wnR-0003n7-Hc for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wnR-0003mz-7x for manet@ietf.org; Wed, 20 Jun 2007 05:48:17 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wnP-0007bQ-TD for manet@ietf.org; Wed, 20 Jun 2007 05:48:17 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5K9mEfD002944 for ; Wed, 20 Jun 2007 10:48:14 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5K9mEHZ023992 for ; Wed, 20 Jun 2007 10:48:14 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 20 Jun 2007 10:48:14 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:48:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Wed, 20 Jun 2007 10:48:14 +0100 Message-ID: In-Reply-To: <003701c7b31f$c7c2f7f0$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New definition of term 'TLV' in PacketBB Thread-Index: AceymUW0mQeveswLRey0yCjxf3+nEgAfKfvwAAHAF1AAAGXhMAAANkwAAAAubnA= From: "Dearlove, Christopher \(UK\)" To: "Teco Boot" X-OriginalArrivalTime: 20 Jun 2007 09:48:14.0448 (UTC) FILETIME=[1F0ADF00:01C7B320] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Besides a lot of references in ML and refs to the ID, I found a ref to "PacketBB" in the DYMO ID, section 4.2: +----------------------------+-------------------+ | Information Location | Notational Prefix | +----------------------------+-------------------+ | IP header | IP. | | UDP header | UDP. | | packetbb message header | MsgHdr. | | packetbb message TLV | MsgTLV. | | packetbb address blocks | AddBlk. | | packetbb address block TLV | AddTLV. | +----------------------------+-------------------+ >>> I suggest that means that (in due course) DYMO should be >>> modified. That will naturally be when packetbb stops >>> being just an ID. Anyway, we need a name for the packet building block. >>> RFC xxxx ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 06:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xW5-0007zp-3A; Wed, 20 Jun 2007 06:34:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0xW3-0007zY-S3 for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 06:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xW3-0007zQ-Gm for manet@ietf.org; Wed, 20 Jun 2007 06:34:23 -0400 Received: from hpsmtp-eml13.kpnxchange.com ([213.75.38.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xW3-0001KG-6o for manet@ietf.org; Wed, 20 Jun 2007 06:34:23 -0400 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml13.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:34:21 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:34:20 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" Subject: RE: [manet] New definition of term 'TLV' in PacketBB Date: Wed, 20 Jun 2007 12:35:16 +0200 Message-ID: <003e01c7b326$b2004600$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AceymUW0mQeveswLRey0yCjxf3+nEgAfKfvwAAHAF1AAAGXhMAAANkwAAAAubnAAARNogA== X-OriginalArrivalTime: 20 Jun 2007 10:34:20.0929 (UTC) FILETIME=[8FFE5F10:01C7B326] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Do you really mean whe should replace short names with RFC IDs? The table would look like: +----------------------------+-------------------+ | Information Location | Notational Prefix | +----------------------------+-------------------+ | RFC791 header | PktHdr. | | RFC768 header | DgrmHdr. | | RFCxxxx message header | MsgHdr. | | RFCxxxx message TLV | MsgTLV. | | RFCxxxx address blocks | AddBlk. | | RFCxxxx address block TLV | AddTLV. | +----------------------------+-------------------+ I know I overdo it. General used objects would be assigned a name and abbreviation. I don't care if it would be PacketBB or GMPMF (Generalized MANET Packet/Message Format) or something else. I won't opt for RFCxxxx. But that is just me. Teco > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: woensdag 20 juni 2007 11:48 > To: Teco Boot > Cc: manet > Subject: RE: [manet] New definition of term 'TLV' in PacketBB > > > Besides a lot of references in ML and refs to the ID, I found a ref to > "PacketBB" in the DYMO ID, section 4.2: > > +----------------------------+-------------------+ > | Information Location | Notational Prefix | > +----------------------------+-------------------+ > | IP header | IP. | > | UDP header | UDP. | > | packetbb message header | MsgHdr. | > | packetbb message TLV | MsgTLV. | > | packetbb address blocks | AddBlk. | > | packetbb address block TLV | AddTLV. | > +----------------------------+-------------------+ > > >>> I suggest that means that (in due course) DYMO should be > >>> modified. That will naturally be when packetbb stops > >>> being just an ID. > > Anyway, we need a name for the packet building block. > > >>> RFC xxxx > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 08:03:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yuW-0002dx-Gs; Wed, 20 Jun 2007 08:03:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0jOl-0000Jr-SR for manet-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:29:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I0jOl-0000Jj-JD for manet@ietf.org; Tue, 19 Jun 2007 15:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gST-0006QG-57 for manet@ietf.org; Tue, 19 Jun 2007 12:21:33 -0400 Received: from sxt-sm-1.ucis.dal.ca ([129.173.5.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gSR-0005ZB-TM for manet@ietf.org; Tue, 19 Jun 2007 12:21:33 -0400 Received: from KIL-UPT-5.UCIS.Dal.Ca (KIL-UPT-5.UCIS.Dal.Ca [129.173.1.165]) by SXT-SM-1.UCIS.Dal.Ca (8.12.11/8.12.10) with ESMTP id l5JGLVt8030169 for ; Tue, 19 Jun 2007 13:21:31 -0300 Received: from KIL-UPT-5.UCIS.Dal.Ca (localhost.localdomain [127.0.0.1]) by KIL-UPT-5.UCIS.Dal.Ca (8.12.11.20060308/8.12.11) with ESMTP id l5JGLVgV017667 for ; Tue, 19 Jun 2007 13:21:31 -0300 Received: (from apache@localhost) by KIL-UPT-5.UCIS.Dal.Ca (8.12.11.20060308/8.12.11/Submit) id l5JGLVEE017665 for manet@ietf.org; Tue, 19 Jun 2007 13:21:31 -0300 Received: from frodo.cs.Dal.Ca (frodo.cs.Dal.Ca [129.173.66.243]) by my5.dal.ca (Horde MIME library) with HTTP for ; Tue, 19 Jun 2007 13:21:31 -0300 Message-ID: <20070619132131.zb7xg18vglbksoo4@my5.dal.ca> Date: Tue, 19 Jun 2007 13:21:31 -0300 From: Tarak Shingne To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-TMDA-Confirmed: Tue, 19 Jun 2007 15:29:55 -0400 X-Mailman-Approved-At: Wed, 20 Jun 2007 08:03:42 -0400 Subject: [manet] Monitoring tool for OLSR ( Proactive Protocol) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello, I am currently working on intrusion detection tools available for the Reactive protocols like AODV and for the Proactive protocols like OLSR. I know watchdog and pathrater which are for reactive protocols. But, i am unable to find one for the olsr. I am curious about this information. Can anyone help me getting this information . Any related help would be highly appreciated. Thanks Tarak _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jun 20 13:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13wY-0006QZ-Bb; Wed, 20 Jun 2007 13:26:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I13wW-0006NL-Sm for manet-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 13:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13wW-0006Kq-HQ for manet@ietf.org; Wed, 20 Jun 2007 13:26:08 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13wV-0003BA-3p for manet@ietf.org; Wed, 20 Jun 2007 13:26:08 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l5KHQ4Uj018906; Wed, 20 Jun 2007 13:26:04 -0400 (EDT) Message-Id: <200706201726.l5KHQ4Uj018906@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007062013260306654 ; Wed, 20 Jun 2007 13:26:03 -0400 From: "Justin Dean" To: "'Alexandru Petrescu'" Subject: RE: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Date: Wed, 20 Jun 2007 13:30:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AceyiYqpLO9IyTnhQOarV0mDdIx3DAAveRiA In-Reply-To: <4677FB21.3070904@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Here is a quick attempt of at an example packet looking to do what I think you are wanting to do. Sample IPv6 values used addr=2001:471:1f11:246:: prefix=64 A packetbb packet is = {*}? {*}* We don't need the packet header or more than one message for this example so. = * A message is defined by = {}* = is a required and is an 8 bit field. For this example lets use a value of MANEMO_TYPE doing this one would be required to set the requirements of how packetbb is to be used and for official use one would have to get an iana assigned message type. 11110000 <-describs an empty msg-header-info field (alternatively one could use the o-address field if there was only ever one network to describe and use the message tlv to give the netmask of that address.) this one we will come back to as it includes fields we haven't gotten to yet is a required 16 bit field though An empty msg-header-info field as defined by the msg-semantics, empty in this case meanting non-existant. Notice that all fields are optional and in this case not used. = ? ? ? ? = * <- not required with tlv-length of 0 We don't need any information here so = 0 (16 bits) So far we have = <- defined <-defined {}* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (block ) | {}* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MANEMO_TYPE | 11110000 | ? | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | {}* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For this case our message MANEMO_TYPE would define that at least one addr-block and one address tlv block is required. = will be 1 for this case (8 bits) turn off the head fields and set the zerotail bit 10100000 ? <-not needed for one address ? <-not needed for one address ? <-to compress the address we will set the tail length of 64. ? <-not needed with zerotail bit set * mid-length = 128 - 0 - 64 = 1 (8 bits) = 64 (8 bits) (zerotail bit is set so tail consists of all zeros) = 2001:471:1f11:246 (in hex 64 bits) = don't know how large it is yet we will fill this in later (16 bits) * = 8 bits lets use the PREFIX_LENGTH type specified in packetbb section 6.1 so type is 0 00010000 <-denoting an 8 bit length field and a single index ? <-this will be set to 0 (8 bits) indicating the first (only) address ? <- this will not be included because of the semantics bit singleindex being set ? <- 8 bit field set to 00000001 (note: we need to specify that single-length is in octets not bits)* ? <-the length of our netmask 01000000 So put everything together and we get +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (block) | || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | (block) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MANEMO_TYPE | 11110000 | 24 (dec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 1 | 10100000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 (dec) | | +-+-+-+-+-+-+-+-+ + | 2001:471:1f11:246 (hex) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 5 (dec) | PREFIX_LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00010000 | 0 | 1 | 64 (dec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As you can see there is overhead from the most efficent way you could send one ipv6 address and its netmask size. However this method would allow for more addresses of similar prefixes to be added with less and less percent overhead as more addresses are added to the address block. I hope this was helpful as an exercise and that it is taken as an only an example of how something could be done with packetbb as I am sure there are other ways as well. There could also be mistakes as well. I also just wanted to point out that the complexity vs. overhead vs. flexability is an issue we have tried to put a lot of thought into. Echoing Thomas I think we are just about where we want to be balancing all three. (with the exception of the possible optional extened type field for both tlv's and message types) Justin Dean -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, June 19, 2007 11:50 AM To: Dearlove, Christopher (UK) Cc: manet Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB Dearlove, Christopher (UK) wrote: >> I came up with the datagram I present first. > > I'm afraid I don't have time to comment on this. Thanks, I request MANET community to comment on that PAcketBB encoding of the IPv6 Mobile Network PRefix - thank you. > But that Pad octet is clearly out of place. > Padding occurs (optionally) only after a packet header or a message. Ok, I moved Pad '0' at the end, it looks like this, is this better? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || |IPv6 address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +- -+ | | +- IPv6 Address -+ | | +- +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PrefixLen | Pad '0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Also see Thomas's comments. I hope someone can comment on this packet format: ok or not ok, how should I encode it better? Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 21 05:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1J0u-0003nB-2T; Thu, 21 Jun 2007 05:31:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1J0s-0003n2-IP for manet-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 05:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1J0s-0003mq-4D for manet@ietf.org; Thu, 21 Jun 2007 05:31:38 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1J0r-0006U5-M0 for manet@ietf.org; Thu, 21 Jun 2007 05:31:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1182418296!16118216!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24759 invoked from network); 21 Jun 2007 09:31:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 21 Jun 2007 09:31:36 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5L9VWON021583; Thu, 21 Jun 2007 02:31:32 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5L9VV4R027423; Thu, 21 Jun 2007 04:31:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5L9VUUk027403; Thu, 21 Jun 2007 04:31:30 -0500 (CDT) Message-ID: <467A4571.40405@gmail.com> Date: Thu, 21 Jun 2007 11:31:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Justin Dean Subject: Re: [manet] Encoding an IPv6 Mobile Network Prefix with PacketBB References: <200706201726.l5KHQ4Uj018906@s2.itd.nrl.navy.mil> In-Reply-To: <200706201726.l5KHQ4Uj018906@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000751-0, 20/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Justin Dean wrote: > Here is a quick attempt of at an example packet looking to do what I > think you are wanting to do. Sample IPv6 values used > addr=2001:471:1f11:246:: prefix=64 [...] > So put everything together and we get > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | || | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (block) | || > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | (block) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > || | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MANEMO_TYPE | 11110000 | 24 (dec) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | 1 | 10100000 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 8 (dec) | | > +-+-+-+-+-+-+-+-+ + > | 2001:471:1f11:246 (hex) | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 5 (dec) | PREFIX_LENGTH | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 00010000 | 0 | 1 | 64 (dec) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks for this picture, I will include it in my description as a way PacketBB encodes an IPv6 Mobile Network Prefix. > As you can see there is overhead from the most efficent way you could > send one ipv6 address and its netmask size. However this method > would allow for more addresses of similar prefixes to be added with > less and less percent overhead as more addresses are added to the > address block. Yes, I agree, and the degree of overhead reduction (compared to full encoding) depends also on the number of common most significant bits these addresses have (intuitively, the more common most significant bits the less overhead). > I hope this was helpful as an exercise and that it is taken as an > only an example of how something could be done with packetbb as I am > sure there are other ways as well. There could also be mistakes as > well. I will take it as the best suggestion as of now, thank you. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 21 07:32:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Ku6-0005hr-LS; Thu, 21 Jun 2007 07:32:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1Ku4-0005hf-1z for manet-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 07:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Ku3-0005hU-12 for manet@ietf.org; Thu, 21 Jun 2007 07:32:43 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Ku1-0002OL-KU for manet@ietf.org; Thu, 21 Jun 2007 07:32:42 -0400 Received: by wr-out-0506.google.com with SMTP id 36so510159wra for ; Thu, 21 Jun 2007 04:32:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pZkFXjYe+TO84EHnBMm5QvXZ2SP9YvuUjZNPjQHHvXtNr65tZJRBf8xUHBtVm6SBwEVSRF+LYxWWL7zF8F+rbTSbGHU6Pv4rM1GyAepsZJwfRv/23+ISgMKVdsmT7HYLDoBRM9bOpHaaDZmICYlaVC6N9hRH8/8KYqW4PxAu3lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=meSEiPFJi4qRIPGf9JzmXQyjNfolxUhUi6YeQE+SrY5R1dfvvBDHnaR5subir+5SRxVcHeH04BGit5+J5vghJAUHqxXm5EKhF+5OY9+0rwVY5uqzuV8wzgC7P899nCsl3oiQxTpIcvnwcjVZO3fJ0Gbn5dnFUzvs8pK8Hlnvfv0= Received: by 10.78.168.1 with SMTP id q1mr856831hue.1182425560623; Thu, 21 Jun 2007 04:32:40 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Thu, 21 Jun 2007 04:32:40 -0700 (PDT) Message-ID: <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> Date: Thu, 21 Jun 2007 17:02:40 +0530 From: "Ian Chakeres" To: manet@ietf.org, "Justin Dean" Subject: Re: [Manet] Expanded tlv type field for packetbb? In-Reply-To: <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Everyone, I would like to solicit your opinion, either for or against including sub-type. Please respond to the list. ============== Justin, I think your metric dilemma is common to many other future TLV types. Here are just a few examples off the top of my head: location/position, name, security. Based on this fact - I think including the sub-type would be useful. I also like the fact that inclusion of sub-type is very straightforward, does not impact existing work, and expands the tlv space for a large number of future tlvs. I look forward to seeing the metric document. Ian On 6/12/07, Justin Dean wrote: > There has been some discussion among the authors of packetbb on the merits > of adding an optional extended TLV type field (as well as the comments > charlie has posted to the list.) While attempting to write a metric TLV > document based on packetbb, for use with MANET protocols, the issue of how > to include/define multiple metric types without using up a lot of the TLV > type space came up. By using an optional type sub field a generalized > metric TLV document can be written to allow for multiple metric types, > different sized value fields, differing value representations, and how the > metrics are to be used. This can be done with the current TLV type field > but I can easily envision 10s if not 100s of metric types in the future. > With our current space there would be little room for official assignments. > > > The benefits are not limited to an unfinished not yet released TLV metric > document. A TLV type field could be assigned to a commercial or research > entity which would then allow much more flexibility in defining TLVs by > using the subtype field, without having to resort to using the experimental > (and possibly conflicting) TLV type space in the current TLV type field. > > On the negative side TLVs which used the extend type field would be 8 bits > longer per TLV. TLVs which are concerned with 8 bits per TLV would not be > forced to use this subfield however and there would be no extra overhead > involved. An extra semantics bit would be assigned as outlined below. This > would make the specification slightly more complex and only 2 bits would be > left for future use in the semantics field. (In my mind if we aren't using > them they are going to waste and if we have a good use for them we should be > using them) > > The proposed changes would comprise mostly of the following. > > In Section 5.3 change to: > > = > > ? <-new optional field > ? > ? > ? > ? > > > In Section 5.3 change to: > > bit 5 (hassubtype): if cleared ('0'), then is not > included in . If set ('1'), then is > included in . > > bits 6-7: are RESERVED and MUST each be cleared ('0') to be in > accordance with this version of the specification. > > > In Section 5.3 add: > > is an 8 bit field, specifying the subtype of the TLV, > specific to the TLV type and kind (i.e. packet, message, or address > block TLV). > > tlv-subtype is a variable, defined to equal if > present, or 0 otherwise. > > tlv-fulltype is a variable, defined by: > > * tlv-fulltype = 256 * + tlv-subtype; > > > Section 5.3.2 change to: > > TLVs in the same TLV block MUST be sorted in ascending tlv-fulltype > order. > > Two or more TLVs with the same tlv-fulltype associated with the same > address block MUST NOT both cover any address. > > TLVs with the same tlv-fulltype associated with the same address block > MUST be sorted in ascending index-start order. > > > In Section 6.1 Table 5 add column Subtype. In existing row set to 0. > Add new row for subtype 1-255 RESERVED. > > > In Section 7 change to > > A new registry for packet TLV types must be created, with no initial > assignments. Future values in the range 0-127 can be allocated using > standards action [3]. Additionally, values in the range 128-255 are > reserved for private/local use. If a TLV type is allocated a new > registry for subtypes of that type must be created. > > A new registry for message TLV types must be created with no initial > assignments. Future values in the range 0-127 can be allocated using > standards action [3]. Additionally, values in the range 128-255 are > reserved for private/local use. If a TLV type is allocated a new > registry for subtypes of that type must be created. > > A new registry for address block TLV types must be created with > initial assignments as specified in Table 7. Future values in the > range 1-127 can be allocated using standards action [3]. > Additionally, values in the range 128-255 are reserved for private/ > local use. If a TLV type is allocated a new registry for subtypes > of that type must be created. > > Justin Dean > > > > _______________________________________________ > Manet-dt mailing list > Manet-dt@ietf.org > https://www1.ietf.org/mailman/listinfo/manet-dt > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 21 08:13:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1LWq-0001Ql-HN; Thu, 21 Jun 2007 08:12:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1LWo-0001Pj-Is for manet-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 08:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1LWn-0001MM-RL for manet@ietf.org; Thu, 21 Jun 2007 08:12:46 -0400 Received: from smtp2.eurecom.fr ([193.55.113.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1LWm-0004W8-3n for manet@ietf.org; Thu, 21 Jun 2007 08:12:45 -0400 Received: from monza.eurecom.fr ([192.168.106.15]) by smtp2.eurecom.fr with ESMTP; 21 Jun 2007 14:12:42 +0200 X-IronPort-AV: i="4.16,447,1175464800"; d="scan'208"; a="1921062:sNHT22518410" Received: from [172.17.20.174] (krabboss.eurecom.fr [172.17.20.174]) by monza.eurecom.fr (Postfix) with ESMTP id AA0FC3C419; Thu, 21 Jun 2007 14:12:42 +0200 (MEST) Message-ID: <467A6B39.5020100@eurecom.fr> Date: Thu, 21 Jun 2007 14:12:41 +0200 From: Jerome Haerri User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [Manet] Expanded tlv type field for packetbb? References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> In-Reply-To: <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Fethi Filali , Christian Bonnet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian, I am glad to hear that the debate on different metrics is now open ! As you probably know, I am a supporter of the inclusion of a sub-type field, as we proposed some times ago a common geo-localization signaling format based on TLVs and packetBB. Indeed, we think that in order to enhance the capabilities of ad hoc networking protocols, new TLV types might be needed. Even though no protocol using potential new fields have been standardized yet, leaving space for extensions would be a measure that would guarantee the success of packetBB in more generalized applications than or specific extensions to OLSR, DYMO or SMF. And as Justin said, TLVs which are concerned with 8 bits per TLV would not be forced to use this subfield and there would be no extra overhead involved. So, I personally do not see good reasons for not including an expanded TLV type field for packetBB. By the way, we are also looking to seeing the metric document and we are offering our help in the definition and writing process of the new TLV metric document if needed. According to this new document, we will also update our geo-localization draft to make it compliant with the expanded field. Jerome, Fethi, Christian Ian Chakeres wrote: > Everyone, I would like to solicit your opinion, either for or against > including sub-type. Please respond to the list. > ============== > > Justin, I think your metric dilemma is common to many other future TLV > types. > > Here are just a few examples off the top of my head: > location/position, name, security. > > Based on this fact - I think including the sub-type would be useful. > > I also like the fact that inclusion of sub-type is very > straightforward, does not impact existing work, and expands the tlv > space for a large number of future tlvs. > > I look forward to seeing the metric document. > Ian > > On 6/12/07, Justin Dean wrote: >> There has been some discussion among the authors of packetbb on the >> merits >> of adding an optional extended TLV type field (as well as the comments >> charlie has posted to the list.) While attempting to write a metric TLV >> document based on packetbb, for use with MANET protocols, the issue of >> how >> to include/define multiple metric types without using up a lot of the TLV >> type space came up. By using an optional type sub field a generalized >> metric TLV document can be written to allow for multiple metric types, >> different sized value fields, differing value representations, and how >> the >> metrics are to be used. This can be done with the current TLV type field >> but I can easily envision 10s if not 100s of metric types in the future. >> With our current space there would be little room for official >> assignments. >> >> >> The benefits are not limited to an unfinished not yet released TLV metric >> document. A TLV type field could be assigned to a commercial or research >> entity which would then allow much more flexibility in defining TLVs by >> using the subtype field, without having to resort to using the >> experimental >> (and possibly conflicting) TLV type space in the current TLV type field. >> >> On the negative side TLVs which used the extend type field would be 8 >> bits >> longer per TLV. TLVs which are concerned with 8 bits per TLV would >> not be >> forced to use this subfield however and there would be no extra overhead >> involved. An extra semantics bit would be assigned as outlined >> below. This >> would make the specification slightly more complex and only 2 bits >> would be >> left for future use in the semantics field. (In my mind if we aren't >> using >> them they are going to waste and if we have a good use for them we >> should be >> using them) >> >> The proposed changes would comprise mostly of the following. >> >> In Section 5.3 change to: >> >> = >> >> ? <-new optional field >> ? >> ? >> ? >> ? >> >> >> In Section 5.3 change to: >> >> bit 5 (hassubtype): if cleared ('0'), then is not >> included in . If set ('1'), then is >> included in . >> >> bits 6-7: are RESERVED and MUST each be cleared ('0') to be in >> accordance with this version of the specification. >> >> >> In Section 5.3 add: >> >> is an 8 bit field, specifying the subtype of the TLV, >> specific to the TLV type and kind (i.e. packet, message, or address >> block TLV). >> >> tlv-subtype is a variable, defined to equal if >> present, or 0 otherwise. >> >> tlv-fulltype is a variable, defined by: >> >> * tlv-fulltype = 256 * + tlv-subtype; >> >> >> Section 5.3.2 change to: >> >> TLVs in the same TLV block MUST be sorted in ascending tlv-fulltype >> order. >> >> Two or more TLVs with the same tlv-fulltype associated with the same >> address block MUST NOT both cover any address. >> >> TLVs with the same tlv-fulltype associated with the same address block >> MUST be sorted in ascending index-start order. >> >> >> In Section 6.1 Table 5 add column Subtype. In existing row set to 0. >> Add new row for subtype 1-255 RESERVED. >> >> >> In Section 7 change to >> >> A new registry for packet TLV types must be created, with no initial >> assignments. Future values in the range 0-127 can be allocated using >> standards action [3]. Additionally, values in the range 128-255 are >> reserved for private/local use. If a TLV type is allocated a new >> registry for subtypes of that type must be created. >> >> A new registry for message TLV types must be created with no initial >> assignments. Future values in the range 0-127 can be allocated using >> standards action [3]. Additionally, values in the range 128-255 are >> reserved for private/local use. If a TLV type is allocated a new >> registry for subtypes of that type must be created. >> >> A new registry for address block TLV types must be created with >> initial assignments as specified in Table 7. Future values in the >> range 1-127 can be allocated using standards action [3]. >> Additionally, values in the range 128-255 are reserved for private/ >> local use. If a TLV type is allocated a new registry for subtypes >> of that type must be created. >> >> Justin Dean >> >> >> >> _______________________________________________ >> Manet-dt mailing list >> Manet-dt@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet-dt >> -- Jerome Haerri Ph.D Eurecom Institute Mobile Communications Department 2229, Route des Cretes B.P. 193 06904 Sophia-Antipolis Cedex France Office : +33 (0)4 93 00 81 76 Mob : +33 (0)6 10 79 72 83 E-mail : jerome.haerri@eurecom.fr Web : http://www.eurecom.fr/people/haerri.en.htm _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 21 10:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1O70-0007Ni-KG; Thu, 21 Jun 2007 10:58:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1O6z-0007Nd-Up for manet-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 10:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1O6z-0007NQ-Kk for manet@ietf.org; Thu, 21 Jun 2007 10:58:17 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1O6z-0007Jt-6Z for manet@ietf.org; Thu, 21 Jun 2007 10:58:17 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5LEwGSt002789 for ; Thu, 21 Jun 2007 15:58:16 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5LEwGuP013712 for ; Thu, 21 Jun 2007 15:58:16 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 21 Jun 2007 15:58:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:58:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 15:58:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: packetbb-06 Thread-Index: Ace0FJ5bZ6uNExqUQQeNWcG6PtBR9w== From: "Dearlove, Christopher \(UK\)" To: X-OriginalArrivalTime: 21 Jun 2007 14:58:15.0969 (UTC) FILETIME=[98D37910:01C7B414] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [manet] packetbb-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new draft of packetbb (-06) should arrive here soon. This note is just to indicate what is and isn't in it. What isn't in it is any change in the protocol (it's separate from the discussion of TLV subtypes in another thread here). There are a couple of wording tweaks in response to comments (one of which we meant to do in -05 but I accidentally omitted it). Mainly what's new is a new Appendix A. We already had, in what's now Appendix B, pictures of the possible forms of the two trickiest parts of the format - address blocks and TLVs (as well as all other parts of the specification) - but it appeared to us, based on comments we've seen and received, that some worked examples wouldn't hurt, so that's what's in the new Appendix. They don't cover all possible options, but do cover the main ones. Please let us know if you find them useful, or not. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 21 15:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SgX-0006GW-D8; Thu, 21 Jun 2007 15:51:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1Sfr-00050f-S2 for manet-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Sfp-0004wB-F4; Thu, 21 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Sfo-0002Zv-Sv; Thu, 21 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9D287175EC; Thu, 21 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1SfK-0000sl-7s; Thu, 21 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-06.txt Pages : 44 Date : 2007-6-21 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-21115000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-21115000.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Jun 22 14:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nWm-000622-0c; Fri, 22 Jun 2007 14:06:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1nWl-00061w-1T for manet-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 14:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nWk-00061o-O6 for manet@ietf.org; Fri, 22 Jun 2007 14:06:34 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1nWj-0005uw-Hv for manet@ietf.org; Fri, 22 Jun 2007 14:06:34 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l5MI6UMe026679; Fri, 22 Jun 2007 14:06:30 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007062214063015401 ; Fri, 22 Jun 2007 14:06:30 -0400 From: "Joe Macker" To: "'Ian Chakeres'" , References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens><200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> Subject: RE: [Manet] Expanded tlv type field for packetbb? Date: Fri, 22 Jun 2007 14:06:27 -0400 Message-ID: <01b501c7b4f8$0d96bc60$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> Thread-Index: Acez+BijsAs+EQ/HQVmvK8NarEvLHAA/1UtA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org One fan of including sub-type. >-----Original Message----- >From: Ian Chakeres [mailto:ian.chakeres@gmail.com] >Sent: Thursday, June 21, 2007 7:33 AM >To: manet@ietf.org; Justin Dean >Subject: Re: [Manet] Expanded tlv type field for packetbb? > >Everyone, I would like to solicit your opinion, either for or >against including sub-type. Please respond to the list. >============== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 22 16:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1piH-0008Px-Pz; Fri, 22 Jun 2007 16:26:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1piF-0008Pi-Hj for manet-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 16:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1piE-0008PQ-Uz for manet@ietf.org; Fri, 22 Jun 2007 16:26:34 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1piE-0004hk-8b for manet@ietf.org; Fri, 22 Jun 2007 16:26:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5MKQLKK020977; Fri, 22 Jun 2007 23:26:30 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 23:26:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 15:26:22 -0500 Received: from [172.18.141.138] ([172.18.141.138]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 15:26:21 -0500 Message-ID: <467C3069.1070706@nokia.com> Date: Fri, 22 Jun 2007 13:26:17 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Ian Chakeres , jdean@itd.nrl.navy.mil Subject: Re: [Manet] Expanded tlv type field for packetbb? References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil> <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> In-Reply-To: <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 20:26:21.0751 (UTC) FILETIME=[98E12C70:01C7B50B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello folks, As I understand it, some types could have a subtype field, and other types would not have to make any definition for a subtype. So for the types that do not define a subtype field, there would only be the canonical TLV overhead. Wouldn't it be better to have the type be the only determinant of whether or not a subtype field exists? Then we would not have to allocate another semantic bit for the purpose of telling whether or not the subtype field is present. If no bit is allocated from the vector of semantics bits, then I'd be in favor. In fact, I'd even be in favor of having the presence of the semantics bits depend on the type field, so that some types do not need the extra eight bits of overhead. If, instead, it is felt this is too hard to parse for subtype presence, I would instead suggest defining a subtype-able range of types. So, for instance, maybe types 64-127 have subtypes and types 1-63 do not. Regards, Charlie P. ext Ian Chakeres wrote: > Everyone, I would like to solicit your opinion, either for or against > including sub-type. Please respond to the list. > ============== > > Justin, I think your metric dilemma is common to many other future TLV > types. > > Here are just a few examples off the top of my head: > location/position, name, security. > > Based on this fact - I think including the sub-type would be useful. > > I also like the fact that inclusion of sub-type is very > straightforward, does not impact existing work, and expands the tlv > space for a large number of future tlvs. > > I look forward to seeing the metric document. > Ian > > On 6/12/07, Justin Dean wrote: >> There has been some discussion among the authors of packetbb on the >> merits >> of adding an optional extended TLV type field (as well as the comments >> charlie has posted to the list.) While attempting to write a metric TLV >> document based on packetbb, for use with MANET protocols, the issue >> of how >> to include/define multiple metric types without using up a lot of the >> TLV >> type space came up. By using an optional type sub field a generalized >> metric TLV document can be written to allow for multiple metric types, >> different sized value fields, differing value representations, and >> how the >> metrics are to be used. This can be done with the current TLV type >> field >> but I can easily envision 10s if not 100s of metric types in the future. >> With our current space there would be little room for official >> assignments. >> >> >> The benefits are not limited to an unfinished not yet released TLV >> metric >> document. A TLV type field could be assigned to a commercial or >> research >> entity which would then allow much more flexibility in defining TLVs by >> using the subtype field, without having to resort to using the >> experimental >> (and possibly conflicting) TLV type space in the current TLV type field. >> >> On the negative side TLVs which used the extend type field would be 8 >> bits >> longer per TLV. TLVs which are concerned with 8 bits per TLV would >> not be >> forced to use this subfield however and there would be no extra overhead >> involved. An extra semantics bit would be assigned as outlined >> below. This >> would make the specification slightly more complex and only 2 bits >> would be >> left for future use in the semantics field. (In my mind if we aren't >> using >> them they are going to waste and if we have a good use for them we >> should be >> using them) >> >> The proposed changes would comprise mostly of the following. >> >> In Section 5.3 change to: >> >> = >> >> ? <-new optional field >> ? >> ? >> ? >> ? >> >> >> In Section 5.3 change to: >> >> bit 5 (hassubtype): if cleared ('0'), then is not >> included in . If set ('1'), then is >> included in . >> >> bits 6-7: are RESERVED and MUST each be cleared ('0') to be in >> accordance with this version of the specification. >> >> >> In Section 5.3 add: >> >> is an 8 bit field, specifying the subtype of the TLV, >> specific to the TLV type and kind (i.e. packet, message, or >> address >> block TLV). >> >> tlv-subtype is a variable, defined to equal if >> present, or 0 otherwise. >> >> tlv-fulltype is a variable, defined by: >> >> * tlv-fulltype = 256 * + tlv-subtype; >> >> >> Section 5.3.2 change to: >> >> TLVs in the same TLV block MUST be sorted in ascending tlv-fulltype >> order. >> >> Two or more TLVs with the same tlv-fulltype associated with the same >> address block MUST NOT both cover any address. >> >> TLVs with the same tlv-fulltype associated with the same address >> block >> MUST be sorted in ascending index-start order. >> >> >> In Section 6.1 Table 5 add column Subtype. In existing row set to 0. >> Add new row for subtype 1-255 RESERVED. >> >> >> In Section 7 change to >> >> A new registry for packet TLV types must be created, with no initial >> assignments. Future values in the range 0-127 can be allocated using >> standards action [3]. Additionally, values in the range 128-255 are >> reserved for private/local use. If a TLV type is allocated a new >> registry for subtypes of that type must be created. >> >> A new registry for message TLV types must be created with no initial >> assignments. Future values in the range 0-127 can be allocated using >> standards action [3]. Additionally, values in the range 128-255 are >> reserved for private/local use. If a TLV type is allocated a new >> registry for subtypes of that type must be created. >> >> A new registry for address block TLV types must be created with >> initial assignments as specified in Table 7. Future values in the >> range 1-127 can be allocated using standards action [3]. >> Additionally, values in the range 128-255 are reserved for private/ >> local use. If a TLV type is allocated a new registry for subtypes >> of that type must be created. >> >> Justin Dean >> >> >> >> _______________________________________________ >> Manet-dt mailing list >> Manet-dt@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet-dt >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jun 22 18:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rNH-0000Fq-AW; Fri, 22 Jun 2007 18:13:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I1rNF-0000Bn-Lk for manet-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 18:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rNF-00008y-8Q for manet@ietf.org; Fri, 22 Jun 2007 18:13:01 -0400 Received: from mail0.cs.utsa.edu ([129.115.29.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1rNE-0008GU-1S for manet@ietf.org; Fri, 22 Jun 2007 18:13:01 -0400 Received: from pandora2.cs.utsa.edu (pandora2.cs.utsa.edu [129.115.29.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail0.cs.utsa.edu (Postfix) with ESMTP id 988B92AC1 for ; Fri, 22 Jun 2007 17:12:50 -0500 (CDT) Date: Fri, 22 Jun 2007 17:12:50 -0500 (CDT) From: "Xu (Kevin) Su" To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [manet] look for someone who is willing to share hotel in IWCMC'07 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, this is Xu (Kevin) Su, male. I am going to present two papers in IWCMC'07.The hotel rate of Turtle Bay Resort at Honolulu is expensive. Due to limited budget, I want to find someone who is willing to share hotel with me. If you are interested, please email me at xsu@cs.utsa.edu and we can discuss the details. Best, Kevin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jun 23 05:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I21uk-0002Qz-PI; Sat, 23 Jun 2007 05:28:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I21uh-0002Qt-G2 for manet-confirm+ok@megatron.ietf.org; Sat, 23 Jun 2007 05:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I21uh-0002Qk-6a for manet@ietf.org; Sat, 23 Jun 2007 05:28:15 -0400 Received: from web33506.mail.mud.yahoo.com ([68.142.206.155]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I21uf-0007tJ-11 for manet@ietf.org; Sat, 23 Jun 2007 05:28:15 -0400 Received: (qmail 28411 invoked by uid 60001); 23 Jun 2007 09:28:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TkNRDNTvbI9XVV3fe1CoRi86ZuMstntQHC/eBZADY8icYuYMwLrKPyaAHyKzLWgYsvMh4KbCDYsWTgsgucaBo2kI+tUpbSMeCsxP2VGOZFfqzm2+QamvjjUHq1pokRAFJphjcj2OZXcTO9ZaLzNdlZrbd0JcQXc+rmAYbhwwwDA=; X-YMail-OSG: x_xOWbEVM1kUif96unn6cFhYDu2hvoDXq.PgQLNYZvP3j68jJOTGfjbxGoprDQzxPja9vA8O.G7m8uyThapr_cvKeARh7cWjHm0_O.HlDdcp.40jZZM- Received: from [68.220.229.247] by web33506.mail.mud.yahoo.com via HTTP; Sat, 23 Jun 2007 02:28:12 PDT Date: Sat, 23 Jun 2007 02:28:12 -0700 (PDT) From: Yang Xiao To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <540710.28150.qm@web33506.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [manet] Journal Special issue about Biomedical sensor Networks (Deadline was extended to July 15, 2007) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org (Deadline was extended to July 15, 2007) Journal Special issue about Biomedical sensor Networks Topics (not limited to): Biomedical sensors Biomedical sensor Networks Computing and Communications of Biomedical sensor Networks Routing for Biomedical sensor Networks MAC for Biomedical sensor Networks Wireless Telemedicine etc. ========== Wireless Telemedicine and Applications Call for Papers Wireless telemedicine, a growing new interdisciplinary field, calls for innovation in information and communications technology for facilitating reliable, comprehensive, and quality clinical care service at a distance. It will eventually contribute to improving the quality of healthcare of everyone. Though advances in wireless communications and networking are vital to deliver telemedicine services, they also face great challenges, for example the failure delivery of a service may end up with loss of human lives. This is the motivation behind this special issue. This special issue focuses on the novel and practical ways, but solid contributions, to improve wireless telemedicine and applications. Papers that do not focus on wireless telemedicine and applications will not be reviewed. Specific interests are (but not limited to) in the following areas: Network architectures for wireless telemedicine Mobile service platform for continuity of healthcare Complexity of wireless telemedicine systems New sensor and medical RFID technologies Network privacy and security in healthcare Wireless network research issues to support healthcare Wireless telemedicine applications Electromagnetic interference issues Signal processing techniques in wireless telemedicine systems Authors should follow the EURASIP Journal on Wireless Communications and Networking manuscript format described at the journal site http://www.hindawi.com/journals/wcn/. Prospective authors should submit an electronic copy of their complete manuscript through the EURASIP Journal on Wireless Communications and Networking's Manuscript Tracking System at http://mts.hindawi.com/, according to the following timetable. Manuscript Due July 15, 2007 First Round of Reviews September 1, 2007 Publication Date December 1, 2007 Guest Editors: Yang Xiao, Department of Computer Science, University of Alabama, Tuscaloosa, AL 35487-0290, USA Yi-Bing Lin, Department of Computer Science and Information Engineering, National Chiao Tung University, 30050 Hsinchu, Taiwan Ding-Zhu Du, Department of Computer Science, University of Texas at Dallas, Richardson, TX 75083, USA Hui Chen, AutoZone, Inc., IT Department, Memphis, TN 38103, USA _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 25 04:35:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2k2K-0002Nz-4c; Mon, 25 Jun 2007 04:35:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I2k2I-0002Nd-KG for manet-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 04:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2k2H-0002N1-GR for manet@ietf.org; Mon, 25 Jun 2007 04:35:01 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2k2H-0004gW-2a for manet@ietf.org; Mon, 25 Jun 2007 04:35:01 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5P8YxS8007257 for ; Mon, 25 Jun 2007 09:34:59 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5P8Yxa9025759 for ; Mon, 25 Jun 2007 09:34:59 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 25 Jun 2007 09:34:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 09:34:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Manet] Expanded tlv type field for packetbb? Date: Mon, 25 Jun 2007 09:34:58 +0100 Message-ID: In-Reply-To: <467C3069.1070706@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Manet] Expanded tlv type field for packetbb? Thread-Index: Ace1C6Z0pkm7kZHtST++XVhc+XmhUQB9iVNA References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil><374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> <467C3069.1070706@nokia.com> From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" , "ext Ian Chakeres" , X-OriginalArrivalTime: 25 Jun 2007 08:34:58.0697 (UTC) FILETIME=[B7093F90:01C7B703] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > As I understand it, some types could have a subtype > field, and other types would not have to make any > definition for a subtype. So for the types that do not > define a subtype field, there would only be the > canonical TLV overhead. There would be no overhead if you don't have a subtype. > Wouldn't it be better to have the type be the only > determinant of whether or not a subtype field exists? > Then we would not have to allocate another semantic > bit for the purpose of telling whether or not the > subtype field is present. This I don't agree with. If you allocate a range of types with and without subtypes, then the only difference is whether you check a bit in the type (or something more complicated) or a semantics bit. And the latter has advantages of orthogonality and consistency with the rest of how a TLV is laid out. Any other way of making type define subtype I can't see working (how can an already fielded device learn that IANA have made a new allocation?). > If no bit is allocated from the vector of semantics bits, > then I'd be in favor. In fact, I'd even be in favor of > having the presence of the semantics bits depend > on the type field, so that some types do not need > the extra eight bits of overhead. Again, not in favour. What's the default semantics for a type without semantics? The reason there are these options is to be more efficient. Or in other words the semantics octet costs you one octet, and often saves more. The most obvious illustration of this is something like NHDP's LINK_STATUS. If a node gets into a stable state, with all good links, then all LINK_STATUS values will be SYMMETRIC. And excellent opportunity for a no index, single value TLV with total length four octets. But if you are in a highly dynamic network, with a mix of LINK_STATUS values, that's a good opportunity for a no index (until you have multiple interfaces) multivalue TLV, with total length 3+N octets, where N is the number of (current and recent) neighbours. If you decide to fix on the latter type of TLV only, the former case will cost you N-1 octets. If you decide to fix on the former type of TLV only, you can't do it unless you have a separate address block per LINK_STATUS value. And there are other possibilities. > If, instead, it is felt this is too hard to parse > for subtype presence, I would instead suggest > defining a subtype-able range of types. So, for > instance, maybe types 64-127 have subtypes and > types 1-63 do not. Commented on above. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 25 07:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2mVT-0006pQ-Hx; Mon, 25 Jun 2007 07:13:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I2mVR-0006ag-Uh for manet-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 07:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2mVR-0006Ww-HQ for manet@ietf.org; Mon, 25 Jun 2007 07:13:17 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2mVQ-00014Q-H3 for manet@ietf.org; Mon, 25 Jun 2007 07:13:17 -0400 Received: (qmail 12469 invoked from network); 25 Jun 2007 13:13:14 +0200 Received: from unknown (HELO Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 25 Jun 2007 13:13:14 +0200 From: "Teco_Boot" To: "'Ian Chakeres'" , "'Justin Dean'" Subject: RE: [Manet] Expanded tlv type field for packetbb? Date: Mon, 25 Jun 2007 13:13:38 +0200 Message-ID: <001801c7b719$f4407980$a600800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acez+C4Y4u5AnkGeSbqtQOLSaQYc0ADHonOw In-Reply-To: <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I prefer a protocol that supports extensions. I prefer routing on metrics and not on hop-count. But: I think the subtype implementation needs to be analyzed. I would opt for an flat number space with an extended format (bit indicating small and long number format) and not for hierarchical numbering, this introduces a waste of the number space as most types need only a few subtypes. And subtypes could have to do with multiple main types also. I also opt for an in-depth analysis for the metric type. Flooding lots of metric types doesn't always help. I am working (mostly thinking) on a Uniform Link Metric (ULM) / Uniform Path Metric (UPM), where a single cost value would indicate the level of preference for the link / path. Such a metric is composed on whatever metric type and UPMs can always be compared, to select the shortest path. I do not say I reject the idea flooding metric types, but I have a bad feeling reading: >>>> can easily envision 10s if not 100s of metric types in the future. How can we ever define a standard routing protocol handling all these special cases? I think a router that has this information should incorporate it in the ULM and signal this with UPM. Signaling position information to neighbors could be useful, but in some cases it is available for the upper layer and signaling it twice looks not efficient to me. Teco. > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: donderdag 21 juni 2007 13:33 > To: manet@ietf.org; Justin Dean > Subject: Re: [Manet] Expanded tlv type field for packetbb? > > Everyone, I would like to solicit your opinion, either for or against > including sub-type. Please respond to the list. > ============== > > Justin, I think your metric dilemma is common to many other future TLV > types. > > Here are just a few examples off the top of my head: > location/position, name, security. > > Based on this fact - I think including the sub-type would be useful. > > I also like the fact that inclusion of sub-type is very > straightforward, does not impact existing work, and expands the tlv > space for a large number of future tlvs. > > I look forward to seeing the metric document. > Ian > > On 6/12/07, Justin Dean wrote: > > There has been some discussion among the authors of packetbb on the > merits > > of adding an optional extended TLV type field (as well as the comments > > charlie has posted to the list.) While attempting to write a metric TLV > > document based on packetbb, for use with MANET protocols, the issue of > how > > to include/define multiple metric types without using up a lot of the > TLV > > type space came up. By using an optional type sub field a generalized > > metric TLV document can be written to allow for multiple metric types, > > different sized value fields, differing value representations, and how > the > > metrics are to be used. This can be done with the current TLV type > field > > but I can easily envision 10s if not 100s of metric types in the future. > > With our current space there would be little room for official > assignments. > > > > > > The benefits are not limited to an unfinished not yet released TLV > metric > > document. A TLV type field could be assigned to a commercial or > research > > entity which would then allow much more flexibility in defining TLVs by > > using the subtype field, without having to resort to using the > experimental > > (and possibly conflicting) TLV type space in the current TLV type field. > > > > On the negative side TLVs which used the extend type field would be 8 > bits > > longer per TLV. TLVs which are concerned with 8 bits per TLV would not > be > > forced to use this subfield however and there would be no extra overhead > > involved. An extra semantics bit would be assigned as outlined below. > This > > would make the specification slightly more complex and only 2 bits would > be > > left for future use in the semantics field. (In my mind if we aren't > using > > them they are going to waste and if we have a good use for them we > should be > > using them) > > > > The proposed changes would comprise mostly of the following. > > > > In Section 5.3 change to: > > > > = > > > > ? <-new optional field > > ? > > ? > > ? > > ? > > > > > > In Section 5.3 change to: > > > > bit 5 (hassubtype): if cleared ('0'), then is not > > included in . If set ('1'), then is > > included in . > > > > bits 6-7: are RESERVED and MUST each be cleared ('0') to be in > > accordance with this version of the specification. > > > > > > In Section 5.3 add: > > > > is an 8 bit field, specifying the subtype of the TLV, > > specific to the TLV type and kind (i.e. packet, message, or > address > > block TLV). > > > > tlv-subtype is a variable, defined to equal if > > present, or 0 otherwise. > > > > tlv-fulltype is a variable, defined by: > > > > * tlv-fulltype = 256 * + tlv-subtype; > > > > > > Section 5.3.2 change to: > > > > TLVs in the same TLV block MUST be sorted in ascending tlv-fulltype > > order. > > > > Two or more TLVs with the same tlv-fulltype associated with the same > > address block MUST NOT both cover any address. > > > > TLVs with the same tlv-fulltype associated with the same address > block > > MUST be sorted in ascending index-start order. > > > > > > In Section 6.1 Table 5 add column Subtype. In existing row set to 0. > > Add new row for subtype 1-255 RESERVED. > > > > > > In Section 7 change to > > > > A new registry for packet TLV types must be created, with no initial > > assignments. Future values in the range 0-127 can be allocated using > > standards action [3]. Additionally, values in the range 128-255 are > > reserved for private/local use. If a TLV type is allocated a new > > registry for subtypes of that type must be created. > > > > A new registry for message TLV types must be created with no initial > > assignments. Future values in the range 0-127 can be allocated using > > standards action [3]. Additionally, values in the range 128-255 are > > reserved for private/local use. If a TLV type is allocated a new > > registry for subtypes of that type must be created. > > > > A new registry for address block TLV types must be created with > > initial assignments as specified in Table 7. Future values in the > > range 1-127 can be allocated using standards action [3]. > > Additionally, values in the range 128-255 are reserved for private/ > > local use. If a TLV type is allocated a new registry for subtypes > > of that type must be created. > > > > Justin Dean > > > > > > > > _______________________________________________ > > Manet-dt mailing list > > Manet-dt@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet-dt > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jun 25 17:41:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wJN-0007px-1j; Mon, 25 Jun 2007 17:41:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I2wJL-0007pr-UF for manet-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 17:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wJL-0007pj-Kj for manet@ietf.org; Mon, 25 Jun 2007 17:41:27 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2wJK-0004pU-5W for manet@ietf.org; Mon, 25 Jun 2007 17:41:27 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5PLfKut019423; Tue, 26 Jun 2007 00:41:22 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:41:21 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 16:41:20 -0500 Received: from [172.18.141.146] ([172.18.141.146]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 16:41:19 -0500 Message-ID: <4680367F.80500@nokia.com> Date: Mon, 25 Jun 2007 14:41:19 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" Subject: Re: [Manet] Expanded tlv type field for packetbb? References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil><374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> <467C3069.1070706@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 21:41:19.0624 (UTC) FILETIME=[910F6080:01C7B771] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Christopher, ext Dearlove, Christopher (UK) wrote: >> Wouldn't it be better to have the type be the only >> determinant of whether or not a subtype field exists? >> Then we would not have to allocate another semantic >> bit for the purpose of telling whether or not the >> subtype field is present. >> > > This I don't agree with. If you allocate a range of > types with and without subtypes, then the only difference > is whether you check a bit in the type (or something more > complicated) or a semantics bit. And the latter has > advantages of orthogonality and consistency with the rest > of how a TLV is laid out. Any other way of making type > define subtype I can't see working (how can an already > fielded device learn that IANA have made a new allocation?). > Do you mean to suggest that legacy operations depend on the setting of a bit in the semantic bit vector? What if the subtype were to follow the length byte, and thus be counted along with the other type fields? (Now I realize I did not go back to check the formulation in the original email, sigh...) > >> If no bit is allocated from the vector of semantics bits, >> then I'd be in favor. In fact, I'd even be in favor of >> having the presence of the semantics bits depend >> on the type field, so that some types do not need >> the extra eight bits of overhead. >> > > Again, not in favour. What's the default semantics for > a type without semantics? Whether or not the semantic bit vector is a good idea, depends on how many types we have, and how many of those types use both settings of various bits. I have not been quibbling about this, but anyway it is worth keeping in mind. > The reason there are these > options is to be more efficient. Or in other words the > semantics octet costs you one octet, and often saves > more. The most obvious illustration of this is something > like NHDP's LINK_STATUS. If a node gets into a stable > state, with all good links, then all LINK_STATUS values > will be SYMMETRIC. And excellent opportunity for a > no index, single value TLV with total length four octets. > But if you are in a highly dynamic network, with a mix > of LINK_STATUS values, that's a good opportunity for a > no index (until you have multiple interfaces) multivalue > TLV, with total length 3+N octets, where N is the number > of (current and recent) neighbours. If you decide to > fix on the latter type of TLV only, the former case will > cost you N-1 octets. If you decide to fix on the former > type of TLV only, you can't do it unless you have a > separate address block per LINK_STATUS value. And there > are other possibilities. > I'll try to read NHDP soon, but one could imagine various solutions here, perhaps involving different types or prepended bit vectors. > >> If, instead, it is felt this is too hard to parse >> for subtype presence, I would instead suggest >> defining a subtype-able range of types. So, for >> instance, maybe types 64-127 have subtypes and >> types 1-63 do not. >> > > Commented on above. > Other protocols manage to do this without significant discomfort, so I reckon we could also. To be clear, though, I am just trying to look at alternatives. I do not have strong requirements one way or another about the eventual solution. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jun 26 04:32:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36T4-0000kx-V3; Tue, 26 Jun 2007 04:32:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I36Si-0008EW-CJ for manet-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 04:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36Sh-0008ED-VF for manet@ietf.org; Tue, 26 Jun 2007 04:31:47 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I36Rx-00084q-Gm for manet@ietf.org; Tue, 26 Jun 2007 04:31:47 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l5Q8V0wd013075 for ; Tue, 26 Jun 2007 09:31:00 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l5Q8Ux88024567 for ; Tue, 26 Jun 2007 09:30:59 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 26 Jun 2007 09:30:59 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 09:30:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Manet] Expanded tlv type field for packetbb? Date: Tue, 26 Jun 2007 09:30:59 +0100 Message-ID: In-Reply-To: <4680367F.80500@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Manet] Expanded tlv type field for packetbb? Thread-Index: Ace3caRb3LC9EnZOSt297/KAj3OyrQAWKQvQ References: <00db01c7acf0$c108dae0$6a01a8c0@HerbRubens> <200706121440.l5CEeTf5017185@s2.itd.nrl.navy.mil><374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> <467C3069.1070706@nokia.com> <4680367F.80500@nokia.com> From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 26 Jun 2007 08:30:59.0556 (UTC) FILETIME=[52E8FA40:01C7B7CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >> This I don't agree with. If you allocate a range of >> types with and without subtypes, then the only difference >> is whether you check a bit in the type (or something more >> complicated) or a semantics bit. And the latter has >> advantages of orthogonality and consistency with the rest >> of how a TLV is laid out. Any other way of making type >> define subtype I can't see working (how can an already >> fielded device learn that IANA have made a new allocation?). =20 > Do you mean to suggest that legacy operations depend on the setting > of a bit in the semantic bit vector? I'm not clear what you're suggesting I'm suggesting - which probably means I'm not suggesting it. I'm saying if we have subtypes which may or may not be included as an octet, then within the natural structure of TLVs as defined in packetbb, a semantics bit is the natural way to signal it. In fact if you look back at the origins of packetbb we started with ranges of types with certain properties, but the number of options (not all suggested by us) increased to where that wasn't working, and hence the current semantics octet was born. I don't see any good reason to go back. (I will agree that no solution here is ideal.) > What if the subtype were to follow the length byte, and thus be > counted along with the other type fields? I don't see that as important. I agree that if subtype were signalled by a type bit then I'd naturally put it straight after the type, if it's signalled by a semantics bit it goes after that. But I don't see that as significant. =20 > Whether or not the semantic bit vector is a good idea, depends on > how many types we have, and how many of those types use both > settings of various bits. I have not been quibbling about this, but > anyway it is worth keeping in mind. I believe we are well past worth keeping in mind, with the implication we may change it later, time. I, and many other people, are not interested in a later, we need to get this finished. > I'll try to read NHDP soon, but one could imagine various solutions here, > perhaps involving different types or prepended bit vectors. Of course there are other solutions. But this is one, and absent a serious objection - which there has been over a year to lodge - a redesign is not called for and we don't have the time for. > To be clear, though, I am just trying to look at > alternatives. I do not have strong requirements one > way or another about the eventual solution. I'm not interested in an eventual solution, I'm interested in a solution now - in fact now is already considerably later than it should be. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 28 08:53:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tUl-0001B6-7Z; Thu, 28 Jun 2007 08:53:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I3tUj-00017L-SN for manet-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 08:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tUj-00017C-Io for manet@ietf.org; Thu, 28 Jun 2007 08:53:09 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3tUb-00039t-Dd for manet@ietf.org; Thu, 28 Jun 2007 08:53:09 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1183035180!994825!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 7271 invoked from network); 28 Jun 2007 12:53:00 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-153.messagelabs.com with SMTP; 28 Jun 2007 12:53:00 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l5SCquiY004518 for ; Thu, 28 Jun 2007 05:53:00 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5SCqtYa009395 for ; Thu, 28 Jun 2007 07:52:55 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5SCqrwf009319 for ; Thu, 28 Jun 2007 07:52:54 -0500 (CDT) Message-ID: <4683AF1C.3000601@gmail.com> Date: Thu, 28 Jun 2007 14:52:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-2, 27/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [manet] Intermediate DYMO Node and MANEMO Mobile Router X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I think section 5.3.3 of DYMO draft (Intermediate Node RREP Creation) is a potential tool for accommodating a MANEMO MR-LFN combination. Whereas generally DYMO assumes the destination IP address of an application be on a node that runs DYMO, a MANEMO MR-LFN network does not assume LFN runs DYMO nor anything else related to mobility. However, DYMO specifies that an intermediary node could reply to a RREQ that traverses it, and this intermediary node could be the MANEMO Mobile Router responding to a RREP on behalf of LFN. But contrary to the DYMO spec text: > The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ > TargetNode, so that the RREQ TargetNode receives routing information > on how to reach the RREQ OrigNode. The Intermediate Node that is a MANEMO Mobile Router should _not_ send a gratuitous RREP to RREQ's Target Node, because that address is either its own (MR's) address or LFN's address, and LFN doesn't understand DYMO. Thoughts? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jun 28 15:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I400u-0002Bn-IP; Thu, 28 Jun 2007 15:50:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I400f-00024O-MT for manet-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I400f-00023y-A9; Thu, 28 Jun 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I400f-00037N-0u; Thu, 28 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DB0D22ACBE; Thu, 28 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I400A-0005Pv-JW; Thu, 28 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 28 Jun 2007 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-smf-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Simplified Multicast Forwarding for MANET Author(s) : J. Macker, et al. Filename : draft-ietf-manet-smf-05.txt Pages : 46 Date : 2007-6-28 This document describes the Simplified Multicast Forwarding (SMF) protocol. SMF provides a basic IP multicast forwarding capability suitable for mobile ad-hoc networks (MANET). SMF applicability is limited to providing multicast forwarding within MANET routing regions. SMF specifies mechanisms to provide temporally unique multicast packet identification for the purpose of enabling MANET- specific duplicate packet detection (DPD). SMF also specifies the operation of DPD maintenance and checking for both sequence-based and hash-based methods. For IPv6, a hop-by-hop option header is specified that assists in the overall DPD process. The optional operation of intermediate devices, called taggers, is also specified and relates to potential use with multiple border routers. SMF is designed to take advantage of reduced relay sets for efficient MANET multicast forwarding and the document describes use and interaction with a number of approaches. Pseudocode and additional educed relay set discussion is provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work in this area remains and is beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-smf-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-smf-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-28134344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-smf-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-smf-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-28134344.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Jun 29 02:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I49fz-0000Xc-DD; Fri, 29 Jun 2007 02:09:51 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I49fw-0000XU-NS for manet-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 02:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I49fw-0000XM-BX for manet@ietf.org; Fri, 29 Jun 2007 02:09:48 -0400 Received: from web35403.mail.mud.yahoo.com ([66.163.179.112]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I49fK-0002A8-BJ for manet@ietf.org; Fri, 29 Jun 2007 02:09:48 -0400 Received: (qmail 46735 invoked by uid 60001); 29 Jun 2007 06:02:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=4I2dSc9wktFeVrjTnwQEuEL8RzloJYSahEK/vm2IHu6q5o6A2JJw8PyNAx1vZZS13P3od/zjxA3/YwUqrpiCfavqoca+5REjRQA3G0CRd7FxgOcbQ57BrhADqUlR1QNCvox/z0jGlE97m/GERZaR4aKRkFxyzdhMkWfzsaqOLxU=; X-YMail-OSG: Oa.CdtEVM1nm9LgJ0_oDf_22A0iaCeLIPA6z59uPsYIW6bhYOKK7l0meuzRuRm7HOcr_wBkAQLPqMk4zKpfx7toesTAFYwCLpczs Received: from [202.184.37.1] by web35403.mail.mud.yahoo.com via HTTP; Thu, 28 Jun 2007 23:02:29 PDT Date: Thu, 28 Jun 2007 23:02:29 -0700 (PDT) From: Farzaneh Razavi Armaghani To: manet@ietf.org MIME-Version: 1.0 Message-ID: <817089.42068.qm@web35403.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] How can I modify TCP delayed ACK for the case d>2? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0970487935==" Errors-To: manet-bounces@ietf.org --===============0970487935== Content-Type: multipart/alternative; boundary="0-348435274-1183096949=:42068" Content-Transfer-Encoding: 8bit --0-348435274-1183096949=:42068 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello all, I want to delay more than 2 ACKs on the TCP receiver side to study the interaction of TCP new reno with the 802.11 MAC protocol in multi-hop ad-hoc networks. How should I modify the TCP delayed acknowledgment mechanism to delay more than 2 ACKs? for example up to 3 or 4 ACK? Regards, Farzaneh. --------------------------------- Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. --0-348435274-1183096949=:42068 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello all,
I want to delay more than 2 ACKs on the TCP receiver side to study the interaction of TCP new reno with the 802.11 MAC protocol in multi-hop ad-hoc networks.
How should I modify the TCP delayed acknowledgment mechanism to delay more than 2 ACKs? for example up to 3 or 4 ACK? 
 
Regards,
Farzaneh.

Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. --0-348435274-1183096949=:42068-- --===============0970487935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0970487935==-- From manet-bounces@ietf.org Fri Jun 29 08:11:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FJZ-0005JV-Jy; Fri, 29 Jun 2007 08:11:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I4EN0-00021C-V5 for manet-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 07:10:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I4EN0-00020k-Eg for manet@ietf.org; Fri, 29 Jun 2007 07:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EKB-0008OD-Lw for manet@ietf.org; Fri, 29 Jun 2007 07:07:39 -0400 Received: from mailgate2.igd.fraunhofer.de ([192.44.32.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4EK7-00007c-03 for manet@ietf.org; Fri, 29 Jun 2007 07:07:39 -0400 Received: from localhost (localhost [127.0.0.1]) by mailgate2.igd.fraunhofer.de (Postfix) with ESMTP id 9B8AF44C3D; Fri, 29 Jun 2007 13:07:32 +0200 (CEST) Received: from [146.140.8.168] (host1960.igd.fhg.de [146.140.8.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.igd.fraunhofer.de (Postfix) with ESMTP id B5DD244648; Fri, 29 Jun 2007 13:07:27 +0200 (CEST) Message-ID: <4684E7EF.3040008@igd.fraunhofer.de> Date: Fri, 29 Jun 2007 13:07:27 +0200 From: Peter Ebinger User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: manet@ietf.org X-Virus-Scanned: by amavisd-new at mailgate2.igd.fraunhofer.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 X-TMDA-Confirmed: Fri, 29 Jun 2007 07:10:34 -0400 X-Mailman-Approved-At: Fri, 29 Jun 2007 08:11:04 -0400 Cc: Fatih Gey Subject: [manet] New release of iNSpect available! A Visualization Tool for MANET Simulations with ns-2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0205467799==" Errors-To: manet-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0205467799== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020504060305060605020405" This is a cryptographically signed message in MIME format. --------------ms020504060305060605020405 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Dear all, a new release of iNSpect is available at http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/. The focus of the new release was a major architectural change to improve the flexibility, the robustness and the efficiency of the tool. iNSpect is a Visualization Tool for MANET Simulations with ns-2. It takes log files (so called trace files) created by the common open source network simulator ns2 and creates a visual presentation of the simulation data. A user can play a simulation (continuously move along the simulation time axis), halt it, jump to a specific simulation time and activate or deactivate more detailed data presentation features. iNSpect provides also the means to take screenshots or record movies. These movies can be shown using common media players independently of iNSpect and are therefore useful for presentations. The focus of iNSpect's visualization is to present movement and data transaction of mobile nodes in MANETs in a clearer way then this has been possible with former tools. Best regards, Peter Ebinger and Fatih Gey ------------------------------------------------------------------------ Background and Application Areas iNSpect was originally written by Neil Mushell and Stuart Kurkowski at Toilers Research Group at the Colorado School of Mines (USA) and was published in 2004. In April 2005 iNSpect version 3.3 has been released. Subsequent development began by Fatih Gey and Peter Ebinger at the Security Technology Department of the Fraunhofer Institute for Computer Graphics Research IGD in Darmstadt (Germany). In late 2005 the development of iNSpect at the Colorado School of Mines by Neil Mushell and Stuart Kurkowski was stopped. The focus of the current developments is major architectural changes to improve the flexibility, the robustness and the efficiency of the tool. Due to these changes, several modules had to be rewritten from scratch with the result, that the current version actually has less features than former versions. However, as a result the new iNSpect version is easily extendable and offers a wide range of possibilities for attachments and for adding new features or expanding the existing ones. Features that are missing at the moment are not meant to be abandoned; they will probably be re-implemented in future releases. Documentation There is a User Manual and a Developers Guide available for iNSpect. - User Manual: The user manual describes how to configure and use iNSpect. The manual presents all functions and features that are currently available. [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/iNSpect_UserManual.pdf] - Developers Guide: The developers guide describes the internals of iNSpect and how it can be extended. [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/iNSpect_DevelopersGuide.pdf] Licensing You are welcome to download and use the iNSpect code free of charge under GNU General Public License, Version 2 [http://www.gnu.org/licenses/gpl.txt]. We only ask you to keep the copyright notices that any published research from using this code includes a reference to the initial technical report about iNSpect: o S. Kurkowski, T. Camp, and M. Colagrosso, A Visualization and Animation Tool for NS-2 Wireless Simulations: iNSpect, Technical Report MCS-04-03, The Colorado School of Mines, June 2004. [PDF] Download iNSpect was implemented and compiled using gcc compiler version 4.0 and below, so far it does not work with any compiler version newer than that. - inspect-allinone-3.4-20070531.tgz (size: 2.4 MB) [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/inspect-allinone-3.4-20070531.tgz] - inspect-3.4-20070531.tgz (size: 314 kB) [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/inspect-3.4-20070531.tgz] Mailing List We set up a public mailing list for discussions related to iNSpect. The target audience are developers and users. Please also send bug reports to this mailing list. We'll do our best to answer questions posted to the list and to provide a fix for a bug as soon as possible. Subscribe to the inspect mailing list by sending a mail to listserv[at]igd.fraunhofer.de with the following information in the mail's body: subscribe inspect Please leave the mail's subject line blank. A few moments later you will receive a confirmation by email. Once subscribed, you are allowed to post messages to mail address inspect[at]igd.fraunhofer.de. Contact: inspect[at]igd.fraunhofer.de Peter Ebinger Fraunhofer-Institut für Graphische Datenverarbeitung IGD E-Mail: peter.ebinger@igd.fraunhofer.de Fatih Gey Fraunhofer-Institut für Graphische Datenverarbeitung IGD E-Mail: fatih.gey@igd.fraunhofer.de -- _______________ | | |_|_|_|_| Fraunhofer-Institut für Graphische Datenverarbeitung |___|___|_|_|_|_| | | |_|_|_|_| Department Security Technology |___|___|_|_|_|_| | . _ _ | Peter Ebinger peter.ebinger@igd.fraunhofer.de | | / _ | \ | Fraunhoferstr. 5 phone +49 6151-155-531 | | \_/ |_/ | 64283 Darmstadt fax +49 6151-155-499 | | Deutschland http://www.igd.fraunhofer.de/igd-a8 ~---------------~ This email is digitally signed - Root-CA: https://pki.fraunhofer.de/ --------------ms020504060305060605020405 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILaTCC Ba4wggSWoAMCAQICAhXFMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA2MDIxNDEyMjUwMVoXDTA5MTIzMTIzMDAwMFowWTELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA0lHRDEPMA0GA1UECxMGUGVvcGxlMRYwFAYD VQQDEw1QZXRlciBFYmluZ2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA17Mj 7508XOCmh/C5UdByPeDz6YuxtDeRCuIPxO1fzmYS/E5I5NPlvesQk+3vfM2WmjRILSBc3+u7 BpRtmRd/Qpr8zUgpvn5Alql10LX7ZyMPDH+28JQ5QaB6HJiBEf/Zhmyi6dJDPLbSvN4K6CKp lg5mMgZ5LpmQbAyYujfttOJtP2AgzrVvaE+3+TM1hd1ZlpgZ/TJeIIJwGS7qiGgRfF6ttWEL aEE/9CmeK/MzyKuXvyB7eP+gcCwBmaXPKu4n1jz485/l7k8eFfj4Vu+5+k6KrnAkbyCkk7rZ 9oiaPm+/DSX+Ryu3/szWVGw6m13Oxh+8F9QCKelGBHgqFGXZFQIDAQABo4ICiDCCAoQwgaAG CWCGSAGG+EIBDQSBkhaBj1NvZnR3YXJlLVplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5n c2luc3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNo ZW47IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHBzOi8vcGtpLmZyYXVuaG9mZXIuZGUvME0G CCsGAQUFBwEBBEEwPzA9BggrBgEFBQcwAYYxaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL0Zo Ry1DQV92Ml9PQ1NQLVJlc3BvbmRlcjBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vcGtpLmZy YXVuaG9mZXIuZGUvRmhHLUNBLUNlcnRzL0ZoRy1DQV92Ml9DUkwuY3JsMAwGA1UdEwEB/wQC MAAwSgYDVR0SBEMwQYEkemVydGlmaXppZXJ1bmdzaW5zdGFuekBmcmF1bmhvZmVyLmRlhhlo dHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvMCoGA1UdEQQjMCGBH3BldGVyLmViaW5nZXJAaWdk LmZyYXVuaG9mZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwIgYDVR0lAQH/BBgwFgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwDgYDVR0PAQH/BAQDAgQwMB0GA1UdDgQWBBQwSrdr2Iqd bsck5EsBAulzvcrlSDAfBgNVHSMEGDAWgBQAw/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkqhkiG 9w0BAQUFAAOCAQEAF5Kwn/wYie8f+2E7TPOMi8hw4AyR3KPoHo86NGxIAQhPCSX9gOKa4nT9 kxAMXMvT3L+y0/PuLXqK43WlCyDYau661Uj799ix7Gx3Xz2hXvSutQji8V22US4jm2laamtq AyAb0YQbB3Ip689kcQqRDWDwwqj18Jszpd+F/WIworXgeaimRnr+h/NdB1Ac3vnSN6rJKdLf isA2YtWyIshs8R5WTp9pjizaG55eJUFLV+cI+Xj5gbrK+ryjzEs2UcHl5d9e+8tLmJKtSl8s XZtqlv1jL71Vna7TmgM8yenuMzVdG8gfk2kGs59o9AacObfiyAS9f1GYfZ2xEHZ0DUQEijCC BbMwggSboAMCAQICAhXEMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA2MDIxNDEyMjQ1MloXDTA5MTIzMTIzMDAwMFowWTELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA0lHRDEPMA0GA1UECxMGUGVvcGxlMRYwFAYD VQQDEw1QZXRlciBFYmluZ2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv9GM K65uJ/WupvV3eUxkYwX77u/S+eo5N+HoHRMFhkYAzmrkbUKR4689+DjIckSGYKyJ1RwRb3IK Fjrv2q/COMC6buD1RiO+vXBcfioQ6gCDobL1J4eIs3tEUvmQyAAhHTT0FsGA+juVTRTeuNXw iLXncUiuuTGG+6wa8ik68IktuNVVPzrDcSvkXliziZAZfCox3jasMbayIEPLP4PzHr2Cb987 vUPH7pA00pFKk76geJQ380SKUhvkZFzJ7+mu3ZftKmvaOjY+kAkTogchHaO3f5lUvn+ZJ34+ DVlKa0ajMyHT/tWA3xlPoy0DrteoQ+EWot/NQUHLD0RZUSD5BQIDAQABo4ICjTCCAokwgaAG CWCGSAGG+EIBDQSBkhaBj1NvZnR3YXJlLVplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5n c2luc3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNo ZW47IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHBzOi8vcGtpLmZyYXVuaG9mZXIuZGUvME0G CCsGAQUFBwEBBEEwPzA9BggrBgEFBQcwAYYxaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL0Zo Ry1DQV92Ml9PQ1NQLVJlc3BvbmRlcjBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vcGtpLmZy YXVuaG9mZXIuZGUvRmhHLUNBLUNlcnRzL0ZoRy1DQV92Ml9DUkwuY3JsMAwGA1UdEwEB/wQC MAAwSgYDVR0SBEMwQYEkemVydGlmaXppZXJ1bmdzaW5zdGFuekBmcmF1bmhvZmVyLmRlhhlo dHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvMCoGA1UdEQQjMCGBH3BldGVyLmViaW5nZXJAaWdk LmZyYXVuaG9mZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYB BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0OBBYEFC26 LXqId9zrEBqDIS6eRyXIL0ZyMB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0G CSqGSIb3DQEBBQUAA4IBAQBY384V4rddhN2+1L2TJYEEi2kBpBMuEMTcpmYlny3vOgEqARV3 pv8hBMs9cCAVesZDM7H5zK2sK9dO0yS5QueWZlLL21o/3eOL9sCx/1cKa2KlGc5B8GcV25J/ 5EkQRULsWW71yL4KROfwmdA32dCZBlFW4P1P10WblclhiKxF8/LOlwRm5CB1EpTHpnxQv2Jl 3ijV4JMig7B01KLruEIA0C5BjdghQXHnftBJpJIlPQTsjSh8CAh4Npc33vNSBzMevl2W19kD Cx8UCxqWmtCa6Mp9e0PLqMSkw4dIwqFYYS+6jtfXuUSSrWE3YItOvUs0pQGoeA56dsT7XvLm mWIkMYIC/zCCAvsCAQEwVTBPMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEr MCkGA1UEAxMiRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgUm9vdC1DQSB2MgICFcQwCQYFKw4D AhoFAKCCAX8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NjI5MTEwNzI3WjAjBgkqhkiG9w0BCQQxFgQUFx9CCpGg466soxx4IUUsv56J6V0wUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwZAYJKwYBBAGCNxAEMVcwVTBPMQswCQYDVQQGEwJE RTETMBEGA1UEChMKRnJhdW5ob2ZlcjErMCkGA1UEAxMiRnJhdW5ob2Zlci1HZXNlbGxzY2hh ZnQgUm9vdC1DQSB2MgICFcUwZgYLKoZIhvcNAQkQAgsxV6BVME8xCzAJBgNVBAYTAkRFMRMw EQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBS b290LUNBIHYyAgIVxTANBgkqhkiG9w0BAQEFAASCAQAFhO7YstCrXfkBIhcJKx8+8iGXbxHD h+3zZtWk8iANuh/S3CSpPrZKJGlDwW96q61bDLUijO0QxAs5tmQviQCBzfZOXd1tseZ0UIA3 HbC3IlnnOkWRgPHBdNYgGdflVvH9hLzyNNHg3WNSNVJXDvlHvjAcyyItGJs0UXDGXyfHz3SV ByeE/T+6jtTTANS9fdfYzglLqM3p/y9svOWNZAwmsjTGXzHPwICD7iP/K5Bp9c378JLZF1K1 XVoTgRYBoo0VQrwgXgDFRvaTSFuMmjQkUL+dGZV7UqIZ2SuprXe3/BwWUgcUc3LZH/MhD7P0 9REdcH2MdWuK0/WoqFZZiLa0AAAAAAAA --------------ms020504060305060605020405-- --===============0205467799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0205467799==-- From manet-bounces@ietf.org Fri Jun 29 20:26:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Qmn-0000ur-7d; Fri, 29 Jun 2007 20:26:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I4Qmm-0000uk-0w for manet-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 20:26:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I4Qml-0000uc-Nt for manet@ietf.org; Fri, 29 Jun 2007 20:25:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Qkl-0008QL-Jm for manet@ietf.org; Fri, 29 Jun 2007 20:23:55 -0400 Received: from incantation.mines.edu ([138.67.130.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Qkl-0000O9-4H for manet@ietf.org; Fri, 29 Jun 2007 20:23:55 -0400 Received: from [192.168.1.4] (vpn15.Mines.EDU [138.67.129.15]) by incantation.Mines.EDU (8.13.1/8.13.1) with ESMTP id l5U0NbT3013983; Fri, 29 Jun 2007 18:23:38 -0600 In-Reply-To: <4684E7EF.3040008@igd.fraunhofer.de> References: <4684E7EF.3040008@igd.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Tracy Camp Date: Fri, 29 Jun 2007 18:28:59 -0600 To: manet@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 X-TMDA-Confirmed: Fri, 29 Jun 2007 20:25:59 -0400 Cc: Fatih Gey , Peter Ebinger Subject: [manet] Re: New release of iNSpect available! A Visualization Tool for MANET Simulations with ns-2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org For those unaware of the iNSpect software being discussed here, =20 please see: http://toilers.mines.edu/Public/NsInspect Peter and Fatih have done a nice job of re-implementing parts of our =20 iNSpect tool (version 3.3). While their iNSPect tool does not include =20= all the features that we offer with our iNSPect tool, they have =20 definitely improved upon our original code structure. I do, however, want to clarify a few items on this "new release of =20 iNSpect". - While it is true that development of new features in iNSpect is not =20= on-going at the Colorado School of Mines, we do provide maintenance =20 and support for our iNSpect software. - Peter and Fatih state that "iNSpect was implemented and compiled =20 using gcc compiler version 4.0 and below, so far it does not work =20 with any compiler version newer than that." This is true of our =20 version 3.3 of iNSpect and Peter/Fatih's version of iNSpect. We have =20 recently released version 3.4 of iNSpect, which does compile with gcc =20= 4.+. Peter and I are talking about ways to help ensure confusion is =20 avoided between this 'new release of iNSpect' (from Peter and Fatih) =20= and the original version of iNSpect (from Toilers). Peter/Fatih: thanks for improving the code structure of a very =20 popular visualization tool. Tracy Tracy Camp, Ph.D. Director of Toilers Dept. of Math. & Computer Sciences (MCS) Colorado School of Mines 303/384-2184 email: tcamp@mines.edu Homepage: http://www.mines.edu/fs_home/tcamp/ Research Group Webpage: http://toilers.mines.edu On Jun 29, 2007, at 5:07 AM, Peter Ebinger wrote: > Dear all, > > a new release of iNSpect is available at > http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/. The > focus of the new release was a major architectural change to =20 > improve the > flexibility, the robustness and the efficiency of the tool. > > iNSpect is a Visualization Tool for MANET Simulations with ns-2. It > takes log files (so called trace files) created by the common open > source network simulator ns2 and creates a visual presentation of the > simulation data. > > A user can play a simulation (continuously move along the simulation > time axis), halt it, jump to a specific simulation time and =20 > activate or > deactivate more detailed data presentation features. iNSpect provides > also the means to take screenshots or record movies. These movies =20 > can be > shown using common media players independently of iNSpect and are > therefore useful for presentations. > > The focus of iNSpect's visualization is to present movement and data > transaction of mobile nodes in MANETs in a clearer way then this has > been possible with former tools. > > Best regards, > Peter Ebinger and Fatih Gey > > > ----------------------------------------------------------------------=20= > -- > > Background and Application Areas > > iNSpect was originally written by Neil Mushell and Stuart Kurkowski at > Toilers Research Group at the Colorado School of Mines (USA) and was > published in 2004. In April 2005 iNSpect version 3.3 has been =20 > released. > Subsequent development began by Fatih Gey and Peter Ebinger at the > Security Technology Department of the Fraunhofer Institute for =20 > Computer > Graphics Research IGD in Darmstadt (Germany). In late 2005 the > development of iNSpect at the Colorado School of Mines by Neil Mushell > and Stuart Kurkowski was stopped. > > The focus of the current developments is major architectural =20 > changes to > improve the flexibility, the robustness and the efficiency of the =20 > tool. > Due to these changes, several modules had to be rewritten from scratch > with the result, that the current version actually has less features > than former versions. However, as a result the new iNSpect version is > easily extendable and offers a wide range of possibilities for > attachments and for adding new features or expanding the existing =20 > ones. > Features that are missing at the moment are not meant to be abandoned; > they will probably be re-implemented in future releases. > > > Documentation > > There is a User Manual and a Developers Guide available for iNSpect. > - User Manual: The user manual describes how to configure and use > iNSpect. The manual presents all functions and features that are > currently available. > [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/=20 > iNSpect_UserManual.pdf] > - Developers Guide: The developers guide describes the internals of > iNSpect and how it can be extended. > [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/=20 > iNSpect_DevelopersGuide.pdf] > > > Licensing > > You are welcome to download and use the iNSpect code free of charge > under GNU General Public License, Version 2 > [http://www.gnu.org/licenses/gpl.txt]. We only ask you to keep the > copyright notices that any published research from using this code > includes a reference to the initial technical report about iNSpect: > o S. Kurkowski, T. Camp, and M. Colagrosso, > A Visualization and Animation Tool for NS-2 Wireless > Simulations: iNSpect, Technical Report MCS-04-03, The Colorado =20 > School of > Mines, June 2004. [PDF] > > > Download > > iNSpect was implemented and compiled using gcc compiler version 4.0 =20= > and > below, so far it does not work with any compiler version newer than =20= > that. > - inspect-allinone-3.4-20070531.tgz (size: 2.4 MB) > [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/=20 > inspect-allinone-3.4-20070531.tgz] > - inspect-3.4-20070531.tgz (size: 314 kB) > [http://www.igd.fraunhofer.de/igd-a8/en/projects/mobsec/inspect/=20 > inspect-3.4-20070531.tgz] > > > Mailing List > > We set up a public mailing list for discussions related to iNSpect. =20= > The > target audience are developers and users. Please also send bug reports > to this mailing list. We'll do our best to answer questions posted to > the list and to provide a fix for a bug as soon as possible. > > Subscribe to the inspect mailing list by sending a mail to > listserv[at]igd.fraunhofer.de with the following information in the > mail's body: subscribe inspect > > Please leave the mail's subject line blank. A few moments later you =20= > will > receive a confirmation by email. Once subscribed, you are allowed to > post messages to mail address inspect[at]igd.fraunhofer.de. > > > Contact: > > inspect[at]igd.fraunhofer.de > > Peter Ebinger > Fraunhofer-Institut f=FCr Graphische Datenverarbeitung IGD > E-Mail: peter.ebinger@igd.fraunhofer.de > > Fatih Gey > Fraunhofer-Institut f=FCr Graphische Datenverarbeitung IGD > E-Mail: fatih.gey@igd.fraunhofer.de > > > --=20 > _______________ > | | |_|_|_|_| Fraunhofer-Institut f=FCr Graphische =20 > Datenverarbeitung > |___|___|_|_|_|_| > | | |_|_|_|_| Department Security Technology > |___|___|_|_|_|_| > | . _ _ | Peter Ebinger peter.ebinger@igd.fraunhofer.de > | | / _ | \ | Fraunhoferstr. 5 phone +49 6151-155-531 > | | \_/ |_/ | 64283 Darmstadt fax +49 6151-155-499 > | | Deutschland http://www.igd.fraunhofer.de/=20 > igd-a8 > ~---------------~ > > This email is digitally signed - Root-CA: https://pki.fraunhofer.de/ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet